Thread: Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1

PG Bug reporting form <noreply@postgresql.org> writes:
> Steps to Reproduce:
> 1. On a PostgreSQL 16 cluster, set max_slot_wal_keep_size = 500 (or any
> non-default value).
> 2. Initdb a new PostgreSQL 17 cluster.
> 3. Copy the postgresql.conf from 16 to 17.
> 4. Attempt to perform a binary upgrade to PostgreSQL 17 using pg_upgrade
> --check.
> Expected Behavior:
> pg_upgrade should automatically override max_slot_wal_keep_size to -1 as
> required for upgrade mode.

I do not think it is within pg_upgrade's charter to modify your
postgresql.conf file.

However, maybe instead of having check_max_slot_wal_keep_size
throw an error about this, we could make it just silently keep
the value as -1.  There's a nearby thread about silently ignoring
inappropriate GUC settings during initdb [1], and this seems like
it'd be in the same spirit.  Or we could just drop the server-side
check altogether, figuring that it's pg_upgrade's job to see to
that.

BTW, your step 3 above is not very good practice.  It will lose the
entries for any new GUCs added in the new PG version.  While that's
not a functional problem, it does mean that the .conf file's
usefulness as documentation gets worse and worse over time.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/87plejmnpy.fsf%40163.com

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, Jul 6, 2025 at 8:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, maybe instead of having check_max_slot_wal_keep_size
>> throw an error about this, we could make it just silently keep
>> the value as -1.

> Can't we just move this to postmaster.c ~ line 850 ?

max_slot_wal_keep_size is marked PGC_SIGHUP, so in principle it
could be changed after postmaster start.  So if we want a server-side
defense, I don't believe checking at postmaster start is adequate.

In practice, as long as pg_upgrade provides that -c switch, I don't
believe any other GUC source that is allowed to set a PGC_SIGHUP
GUC would override the -c switch.  So the need for any server-side
defense isn't obvious to me.

> This seems no different than wal_level and summarize_wal having a
> co-dependency such that intermediate invalid states must be allowed to
> exist so long as what the server ends up running under is valid.

I think that code doesn't do what its author hoped :-(

Anyway, I found the thread for commit 8bfb231b4 which installed
this code [1], and I'm going to go complain there.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/20231027.115759.2206827438943188717.horikyota.ntt%40gmail.com