Re: A recent message added to pg_upgade
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Amit Kapila <amit.kapila16@gmail.com>
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: 2024-01-11T03:37:58Z
Lists: pgsql-hackers
On Wed, Jan 10, 2024 at 06:02:12PM +0530, Amit Kapila wrote: > - if (max_logical_replication_workers == 0) > + /* > + * The logical replication launcher is disabled during binary upgrades, > + * as logical replication workers can stream data during the upgrade > + * which can cause replication origins to move forward after we have > + * copied them. It can cause the system to request the data which is > + * already present in the new cluster. > + */ > + if (max_logical_replication_workers == 0 || IsBinaryUpgrade) > > This comment is not very clear to me. The first part of the sentence > can't apply to the new cluster as after the upgrade, subscriptions > will be disabled and the second part talks about requesting the wrong > data in the new cluster. As per my understanding, the problem here is > that, on the old cluster, the origins may move forward after we copy > them and then we copy physical files. Now, in the new cluster when we > try to request the data, it will be already present. As far as I understand your complaint is about being more precise about where the workers could run when we do an upgrade. My patch covers the reason why it would be a problem, and I agree that it could be more detailed. Hence, how about something like that: "The logical replication launcher is disabled during binary upgrades, as a logical replication workers running on the cluster upgrading from could cause replication origins to move forward after they are copied to the cluster upgrading to, creating potentially conflicts with the physical files copied over." If you have a better suggestion, feel free. -- Michael
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