Re: A recent message added to pg_upgade
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, smithpb2250@gmail.com,
bharath.rupireddyforpostgres@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2025-07-09T11:59:28Z
Lists: pgsql-hackers
Attachments
- comments.patch.txt (text/plain)
On 2025-Jul-09, Dilip Kumar wrote: > On Wed, Jul 9, 2025 at 9:07 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > After further consideration, I believe your proposed method is > > superior to forcing the max_slot_wal_keep_size to -1 via a check hook. > > The ultimate goal is to prevent WAL removal during a binary upgrade, > > and your approach directly addresses this issue rather than > > controlling it by forcing the GUC value. I am planning to send a > > patch using this approach for both max_slot_wal_keep_size as well as > > for idle_replication_slot_timeout. > > PFA, with this approach. This indeed makes the whole thing a lot simpler and more direct than the original code, and solves this subthread's complaint. It's a bit weird that slot.c and xlog.c now have to worry about IsBinaryUpgrade, but I don't feel any guilt about that. I propose a few comment updates on top of your patch. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible" (Calvin a la TV)
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