Rework how logirep launchers are stopped during pg_upgrade

This is a rework of 7021d3b17664, where we relied on forcing
max_logical_replication_workers to 0 in the postgres command.  This
commit now prevents logical replication launchers to start using -b and
a backend-side check based on IsBinaryUpgrade, effective when upgrading
from 17 and newer versions.

This commit improves the comments explaining why this restriction is
necessary.

This discussion was on hold until we were sure how to add support for
subscribers in pg_upgrade, something now done thanks to 9a17be1e244a.

Reviewed-by: Álvaro Herrera, Amit Kapila, Tom Lane
Discussion: https://postgr.es/m/ZU2TeVkUg5qEi7Oy@paquier.xyz

diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c
index 33f07f674d9204d2eec367ee920898442fe2f686..122db0bb1345929d6dc7d974f8e9c9988b355390 100644 (file)
--- a/src/backend/replication/logical/launcher.c
+++ b/src/backend/replication/logical/launcher.c
@@ -925,7 +925,14 @@ ApplyLauncherRegister(void)
 {
    BackgroundWorker bgw;
 
-   if (max_logical_replication_workers == 0)
+   /*
+    * The logical replication launcher is disabled during binary upgrades, to
+    * prevent logical replication workers from running on the source cluster.
+    * That could cause replication origins to move forward after having been
+    * copied to the target cluster, potentially creating conflicts with the
+    * copied data files.
+    */
+   if (max_logical_replication_workers == 0 || IsBinaryUpgrade)
        return;
 
    memset(&bgw, 0, sizeof(bgw));

diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 64b24270e38d0b0e0ee00dc9feeeeb4ba876a5d1..91bcb4dbc7e694e8ec7d2a905c58dfc8c3c36167 100644 (file)
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -248,19 +248,14 @@ 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 -c max_logical_replication_workers=0");
+       appendPQExpBufferStr(&pgoptions, " -c max_slot_wal_keep_size=-1");
 
-   /* Use -b to disable autovacuum. */
+   /*
+    * Use -b to disable autovacuum and logical replication launcher
+    * (effective in PG17 or later for the latter).
+    */
    snprintf(cmd, sizeof(cmd),
             "\"%s/pg_ctl\" -w -l \"%s/%s\" -D \"%s\" -o \"-p %d -b%s %s%s\" start",
             cluster->bindir,