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

On Sunday, July 6, 2025, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 18979
> Logged by: Jorge Solorzano
> Email address: jorsol(at)gmail(dot)com
> PostgreSQL version: 17.5
> Operating system: Linux
> Description:
>
> The upgrade fails with the following error:
> command: "/usr/pgsql-17/bin/pg_ctl" -w -l
> "/var/lib/pgsql/17/data/pg_upgrade_output.d/20250706T152559.441/log/pg_
> upgrade_server.log"
> -D "/var/lib/pgsql/17/data" -o "-p 50432 -b -c synchronous_commit=off -c
> fsync=off -c full_page_writes=off -c max_slot_wal_keep_size=-1 -c
> listen_addresses='' -c unix_socket_permissions=0700 -c
> unix_socket_directories='/var/lib/pgsql'" start >>
> "/var/lib/pgsql/17/data/pg_upgrade_output.d/20250706T152559.441/log/pg_
> upgrade_server.log"
> 2>&1
> waiting for server to start....2025-07-06 13:25:59.929 GMT [9439] LOG:
> invalid value for parameter "max_slot_wal_keep_size": 500
> 2025-07-06 13:25:59.929 GMT [9439] DETAIL: "max_slot_wal_keep_size" must
> be
> set to -1 during binary upgrade mode.
> 2025-07-06 15:25:59.930 CEST [9439] FATAL: configuration file
> "/var/lib/pgsql/17/data/postgresql.conf" contains errors
> stopped waiting
> pg_ctl: could not start server
> Additional Context:
> While pg_upgrade does pass other required parameters like -c
> max_slot_wal_keep_size=-1 on the command line when starting the new cluster
> in upgrade mode, the value in postgresql.conf appears to override this,
> leading to startup failure.

It doesn’t override it but both the value in the conf and the one on the
startup command are evaluated and the one in the conf causes the failure
before the startup command version can restore the system to a valid
state. I.e., validation is not deferred.

It would be helpful if pg_upgrade temporarily overrides the setting
> correctly, regardless of the static config.
>
>
The existing behavior by pg_upgrade makes sense but it pointless given the
existing implementation of setting handling. It seems doable to remove the
check from the setting area and place it elsewhere.

David J.