Re: Spurious pgstat_drop_replslot() call
От | Michael Paquier |
---|---|
Тема | Re: Spurious pgstat_drop_replslot() call |
Дата | |
Msg-id | Ze6vnAV8qNTJAa_F@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Spurious pgstat_drop_replslot() call (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Spurious pgstat_drop_replslot() call
Re: Spurious pgstat_drop_replslot() call |
Список | pgsql-hackers |
On Fri, Mar 08, 2024 at 03:04:10PM +0000, Bertrand Drouvot wrote: > The switch in the patch from "drop" to "invalidation" is in [1], see: > > " > Given the precedent of max_slot_wal_keep_size, I think it's wrong to just drop > the logical slots. Instead we should just mark them as invalid, > like InvalidateObsoleteReplicationSlots(). > > Makes fully sense and done that way in the attached patch. > “ > > But yeah, hard to be sure why this call is there, at least I don't remember... Yep, noticed that on Friday. > We can not be 100% sure that the stats are up to date when the process holding > the active slot is killed. > > So v2 attached adds a test where we ensure first that we have non empty stats > before triggering the invalidation. Ah, that explains the extra poll. What you have done here makes sense to me, and the new test fails immediately if I add back the stats drop in the invalidation code path. That's a slight change in behavior, unfortunately, and it cannot be called a bug as this improves the visibility of the stats after an invalidation, so this is not something that can be backpatched. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: