From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14228: replication slot catalog_xmin not cleared on slot reuse |
Date: | 2016-07-28 00:24:37 |
Message-ID: | 20160728002437.t4xvmdkgelwwsm75@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2016-07-06 13:07:36 +0900, Michael Paquier wrote:
> _
>
> On Wed, Jul 6, 2016 at 12:56 PM, Andrew Gierth
> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
> >>>>>> "Michael" == Michael Paquier <michael(dot)paquier(at)gmail(dot)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.
I think it'd be better if we explicitly zeroed .data - that way the
likelihood of future bugs of the same ilk is smaller.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-07-28 00:45:18 | Re: BUG #14150: Attempted to delete invisible tuple |
Previous Message | Andres Freund | 2016-07-27 23:53:47 | Re: BUG #14150: Attempted to delete invisible tuple |