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
