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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: jorsol(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
Date: 2025-07-06 16:47:04
Message-ID: CAKFQuwZEB8F3mEymwuTJidLvQ9E1ZzUZEJQzOjP8KKFnLMSemw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Jul 6, 2025 at 9:41 AM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> 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)
>
>
I suppose the answer is because sighup settings seemingly do not belong
here...

./psql postgres
psql (18beta1)
Type "help" for help.

postgres=# show summarize_wal;
summarize_wal
---------------
on
(1 row)

postgres=# show wal_level;
wal_level
-----------
minimal
(1 row)

Which is an impossible combination to begin in but is allowed if you change
only sumamrize_wal to on and perform a reload.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-07-06 17:53:54 Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
Previous Message David G. Johnston 2025-07-06 16:41:02 Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1