Re: A recent message added to pg_upgade - Mailing list pgsql-hackers

From vignesh C
Subject Re: A recent message added to pg_upgade
Date
Msg-id CALDaNm26+iurjTg+qsS=H_ayRRoXB3++x1iZRygHuzr7ezbEmQ@mail.gmail.com
Whole thread Raw
In response to Re: A recent message added to pg_upgade  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: A recent message added to pg_upgade
List 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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Replace remaining getpwuid() calls with getpwuid_r()?
Next
From: Dilip Kumar
Date:
Subject: Re: A recent message added to pg_upgade