Re: A recent message added to pg_upgade

vignesh C <vignesh21@gmail.com>

From: vignesh C <vignesh21@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, 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-10T05:41:33Z
Lists: pgsql-hackers
On Wed, 9 Jul 2025 at 17:47, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> >
> > 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.
>
> Thanks Alvaro for having a look.
>
> > I propose a few comment updates on top of your patch.
>
> This comment updates LGTM, so included in v3.

The patch does not apply on the PG17 branch where the original issue
was reported. I felt we should backbranch this up to PG17 where this
was added.

Regards,
Vignesh



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.