Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
От | Tom Lane |
---|---|
Тема | Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1 |
Дата | |
Msg-id | 215701.1751824434@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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>) |
Список | pgsql-bugs |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Sun, Jul 6, 2025 at 8:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > Can't we just move this to postmaster.c ~ line 850 ? max_slot_wal_keep_size is marked PGC_SIGHUP, so in principle it could be changed after postmaster start. So if we want a server-side defense, I don't believe checking at postmaster start is adequate. In practice, as long as pg_upgrade provides that -c switch, I don't believe any other GUC source that is allowed to set a PGC_SIGHUP GUC would override the -c switch. So the need for any server-side defense isn't obvious to me. > 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. I think that code doesn't do what its author hoped :-( Anyway, I found the thread for commit 8bfb231b4 which installed this code [1], and I'm going to go complain there. regards, tom lane [1] https://www.postgresql.org/message-id/flat/20231027.115759.2206827438943188717.horikyota.ntt%40gmail.com
В списке pgsql-bugs по дате отправления: