Horton

Re: A recent message added to pg_upgade

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: amit.kapila16@gmail.com
Cc: michael@paquier.xyz, smithpb2250@gmail.com, bharath.rupireddyforpostgres@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2023-11-09T06:10:09Z
Lists: pgsql-hackers

Attachments

At Thu, 9 Nov 2023 09:53:07 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in 
> Michael, Horiguchi-San, and others, do you have any thoughts on what
> is the best way to proceed?

As I previously mentioned, I believe that if rejection is to be the
course of action, it would be best to proceed with it sooner rather
than later. On the other hand, I am concerned about the need for users
to perform extra steps depending on the source cluster
conrfiguration. Therefore, another possible approach could be to
simply ignore the given settings in the assignment hook rather than
rejecting by the check hook, and forcibuly apply -1.

What do you think about this third approach?

I haven't checked this with pg_upgrade, but a standalone postmaster
would emit the following messages.

> postgres -b -c max_slot_wal_keep_size=-1
> LOG:  "max_slot_wal_keep_size" is foced to set to -1 during binary upgrade mode.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Fix the handling of two GUCs during upgrade.

  2. Rework how logirep launchers are stopped during pg_upgrade

  3. Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.

  4. Prevent startup of logical replication launcher during pg_upgrade

  5. Migrate logical slots to the new node during an upgrade.