Re: A recent message added to pg_upgade
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Amit Kapila <amit.kapila16@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-05T00:03:06Z
Lists: pgsql-hackers
On Fri, Nov 03, 2023 at 01:33:26PM +1100, Peter Smith wrote: > On Fri, Nov 3, 2023 at 1:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote: >> Now, that Michael also committed another similar change in commit >> 7021d3b176, it is better to be consistent in both cases. So, either we > > I agree. Both patches are setting a special GUC value at the command > line, and both of them don't want the user to somehow override that. > Since the requirements are the same, I felt the implementations > (regardless if they use a guc hook or something else) should also be > done the same way. Yesterday I posted a review comment on the other > thread [1] (#2c) trying to express the same point about consistency. Yeah, I certainly agree about consistency in the implementation for both sides of the coin. Nevertheless, I'm still +-0 on the GUC hook addition as I am wondering if there could be a case where one would be interested in enforcing the state of the GUCs anyway, and we'd prevent entirely that. Another thing that we can do for max_logical_replication_workers, rather than a GUC hook, is to add a check on IsBinaryUpgrade in ApplyLauncherRegister(). At least that would be consistent with what we do for autovacuum as the apply worker is just a bgworker. -- 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