Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse
От | Michael Paquier |
---|---|
Тема | Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse |
Дата | |
Msg-id | CAB7nPqRLLa-4TiSs0viDOcNBqsx0f5KSHWQAFYF17um1CZHfGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-bugs |
On Tue, Jul 26, 2016 at 12:25 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Michael Paquier (michael.paquier@gmail.com) wrote: >> On Wed, Jul 6, 2016 at 12:56 PM, Andrew Gierth >> <andrew@tao11.riddles.org.uk> wrote: >> >>>>>> "Michael" == Michael Paquier <michael.paquier@gmail.com> writes: >> > >> > >> When creating a physical replication slot, the catalog_xmin field of >> > >> the new slot is not initialized. If the slot storage had previously >> > >> been used for a logical slot, the old catalog_xmin will remain in >> > >> place and interfere with vacuum. >> > >> > Michael> Good catch! The same applies to confirmed_flush_lsn, which is >> > Michael> used only by logical decoding and should remain as NULL for >> > Michael> physical slots. So I propose the patch attached to address >> > Michael> both problems. >> > >> > What about slot->effective_catalog_xmin ? >> >> Yes. I guess so, as well as the other candidate_* fields in the slot >> to begin from a clean state. > > Seems like we should try to get this in before the next round of point > releases...? That would be nice, I would guess that Andres or Robert (added in CC) are the best fits to commit this patch, even if this is just a variable initialization issue. -- Michael
В списке pgsql-bugs по дате отправления: