Prevent startup of logical replication launcher during pg_upgrade

The logical replication launcher may start apply workers during an
upgrade.  This could be the cause of corruptions on a new cluster if
these are able to apply changes before the physical files are copied
over to the new cluster.

The chance of being able to do so is small as pg_upgrade uses its own
port and unix domain directory (the latter is customizable with
--socketdir), but just preventing the launcher to start is safer at the
end, because we are then sure that no changes will be applied.  Like
29d0a77 for max_slot_wal_keep_size, this is only set when a cluster
uses v17 or newer.

Author: Vignesh C
Discussion: https://postgr.es/m/CALDaNm2g9ZKf=y8X6z6MsLCuh8WwU-=Q6pLj35NFi2M5BZNS_A@mail.gmail.com

Author: michaelpq

src/bin/pg_upgrade/server.c

@@ -248,9 +248,17 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
 	 * invalidation of slots during the upgrade. We set this option when
 	 * cluster is PG17 or later because logical replication slots can only be
 	 * migrated since then. Besides, max_slot_wal_keep_size is added in PG13.
+	 *
+	 * Use max_logical_replication_workers as 0 to prevent a startup of the
+	 * logical replication launcher while upgrading because it may start apply
+	 * workers that could start receiving changes from the publisher before
+	 * the physical files are put in place, causing corruption on the new
+	 * cluster upgrading to.  Like the previous parameter, this is set only
+	 * when a cluster is PG17 or later as logical slots can only be migrated
+	 * since this version.
 	 */
 	if (GET_MAJOR_VERSION(cluster->major_version) >= 1700)
-		appendPQExpBufferStr(&pgoptions, " -c max_slot_wal_keep_size=-1");
+		appendPQExpBufferStr(&pgoptions, " -c max_slot_wal_keep_size=-1 -c max_logical_replication_workers=0");
 
 	/* Use -b to disable autovacuum. */
 	snprintf(cmd, sizeof(cmd),