From: Tom Lane <tgl@sss.pgh.pa.us>
To: jorsol@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is
 not set to -1
In-reply-to: <18979-a1b7fdbb7cd181c6@postgresql.org>
References: <18979-a1b7fdbb7cd181c6@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 06 Jul 2025 13:58:20 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <200806.1751815611.1@sss.pgh.pa.us>
Date: Sun, 06 Jul 2025 11:26:51 -0400
Message-ID: <200807.1751815611@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/200807.1751815611%40sss.pgh.pa.us>
Precedence: bulk

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