Re: A recent message added to pg_upgade
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Smith <smithpb2250@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, bharath.rupireddyforpostgres@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2023-11-07T10:46:21Z
Lists: pgsql-hackers
On Tue, Nov 7, 2023 at 8:12 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Nov 07, 2023 at 07:59:46AM +0530, Amit Kapila wrote: > > Do you mean to say that if 'IsBinaryUpgrade' is true then let's not > > allow to launch launcher or apply worker? If so, I guess this won't be > > any better than prohibiting at an early stage or explicitly overriding > > those with internal values and documenting it, at least that way we > > can be consistent for both variables (max_logical_replication_workers > > and max_slot_wal_keep_size). > > Yes, I mean to paint an extra IsBinaryUpgrade before registering the > apply worker launcher. That would be consistent with what we do for > autovacuum in the postmaster. > But then we don't need the hardcoded value of max_logical_replication_workers as zero by pg_upgrade. I think doing IsBinaryUpgrade for slots won't be neat, so we anyway need to keep using the special value of max_slot_wal_keep_size GUC. Though the handling for both won't be the same but I guess given the situation, that seems like a reasonable thing to do. If we follow that then we can have this special GUC hook only for max_slot_wal_keep_size GUC. -- With Regards, Amit Kapila.
Commits
-
Fix the handling of two GUCs during upgrade.
- 72e6c08fea7c 19 (unreleased) landed
- f36e5774510d 18.0 landed
- 24f6c1bd41d0 17.6 landed
-
Rework how logirep launchers are stopped during pg_upgrade
- 08c3ad27eb53 17.0 landed
-
Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.
- 8bfb231b43d7 17.0 landed
-
Prevent startup of logical replication launcher during pg_upgrade
- 7021d3b17664 17.0 cited
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 cited