Re: A recent message added to pg_upgade
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, smithpb2250@gmail.com, bharath.rupireddyforpostgres@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2023-11-09T14:24:23Z
Lists: pgsql-hackers
On 2023-Nov-09, Amit Kapila wrote: > These comments appear mostly repetitive to what is already mentioned > in start_postmaster(). So, I have changed those referred to already > written comments, and slightly adjusted the comments at another place. > See attached. I'd still rather mention check_old_cluster_for_valid_slots() just above the Assert() in InvalidatePossiblyObsoleteSlot(). It looks too bare to me otherwise. > Personally, I don't see the need for a test for this, so removed the > same but can add it back if you or others think so. I'm neutral on having a test for this. I'm not sure this is easy to break unintentionally. OTOH the test is cheap, since it only has to run pg_upgrade itself and not, say, another initdb. On the (as Robert says) third hand, would we have tests for each possible GUC that we'd like not to be changed during pg_upgrade? I suspect not, which suggests we don't want this one either. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem)
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