From ab682bfcfbad5e70e288647bb7ebf27d7c5abd74 Mon Sep 17 00:00:00 2001 From: Vignesh C Date: Fri, 27 Oct 2023 11:18:28 +0530 Subject: [PATCH v10 1/2] Prevent startup of logical replication launcher in binary upgrade mode The logical replication launcher may start apply workers during an upgrade, which could be the cause of corruptions on a new cluster if these are able to apply changes before the physical files are copied over. The chance of being able to do so should be small as pg_upgrade uses its own port and unix domain directory (customizable as well with --socketdir), but just preventing the launcher to start is safer at the end, because we are then sure that no changes would ever be applied. Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm2g9ZKf=y8X6z6MsLCuh8WwU-=Q6pLj35NFi2M5BZNS_A@mail.gmail.com --- src/bin/pg_upgrade/server.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index d7f6c268ef..9dedf63a87 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -248,9 +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. + * We don't want the launcher to run while upgrading because it may start + * apply workers which could start receiving changes from the publisher + * before the physical files are put in place, causing corruption on the + * new cluster upgrading to, so setting max_logical_replication_workers=0 + * to disable launcher. */ 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), -- 2.34.1