Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: jorsol@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-07-06T16:41:02Z
Lists: pgsql-bugs
On Sun, Jul 6, 2025 at 8:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > PG Bug reporting form <noreply@postgresql.org> writes: > > > 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. > That isn't what is being asked. They simply want the override that is already in place to actually work. > 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. > Can't we just move this to postmaster.c ~ line 850 ? 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. max_slot_wal_keep_size is sighup just like summarize_wal (and IsBinaryUpgrade behaves like a postmaster GUC) David J.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix the handling of two GUCs during upgrade.
- 72e6c08fea7c 19 (unreleased) landed
- f36e5774510d 18.0 landed
- 24f6c1bd41d0 17.6 landed
-
Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.
- 8bfb231b43d7 17.0 cited