Re: A recent message added to pg_upgade
От | vignesh C |
---|---|
Тема | Re: A recent message added to pg_upgade |
Дата | |
Msg-id | CALDaNm26+iurjTg+qsS=H_ayRRoXB3++x1iZRygHuzr7ezbEmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: A recent message added to pg_upgade (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: A recent message added to pg_upgade
|
Список | pgsql-hackers |
On Wed, 9 Jul 2025 at 17:47, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera <alvherre@kurilemu.de> wrote: > > > > On 2025-Jul-09, Dilip Kumar wrote: > > > > > On Wed, Jul 9, 2025 at 9:07 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > After further consideration, I believe your proposed method is > > > > superior to forcing the max_slot_wal_keep_size to -1 via a check hook. > > > > The ultimate goal is to prevent WAL removal during a binary upgrade, > > > > and your approach directly addresses this issue rather than > > > > controlling it by forcing the GUC value. I am planning to send a > > > > patch using this approach for both max_slot_wal_keep_size as well as > > > > for idle_replication_slot_timeout. > > > > > > PFA, with this approach. > > > > This indeed makes the whole thing a lot simpler and more direct than the > > original code, and solves this subthread's complaint. It's a bit weird > > that slot.c and xlog.c now have to worry about IsBinaryUpgrade, but I > > don't feel any guilt about that. > > Thanks Alvaro for having a look. > > > I propose a few comment updates on top of your patch. > > This comment updates LGTM, so included in v3. The patch does not apply on the PG17 branch where the original issue was reported. I felt we should backbranch this up to PG17 where this was added. Regards, Vignesh
В списке pgsql-hackers по дате отправления: