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.
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 |