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: houzj.fnst@fujitsu.com
Cc: amit.kapila16@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2023-10-30T07:46:42Z
Lists: pgsql-hackers 
At Mon, 30 Oct 2023 03:36:41 +0000, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com> wrote in 
> Thanks for the diff and I think the approach basically works.
> 
> One notable behavior of this approach it will reject the GUC setting even if there
> are no slots on old cluster or user set the value to a big enough value which
> doesn't cause invalidation. The behavior doesn't look bad to me but just mention it
> for reference.

Indeed.  pg_upgrade anyway sets the variable to -1 irrespective of the
slot's existence, and I see no justification for allowing users to
forcibly change it.

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.