Re: Few observations in replication slots related code

On 2014-06-13 14:21:33 +0530, Amit Kapila wrote:
> On Fri, Jun 13, 2014 at 1:45 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
> wrote:
> > On 2014-06-13 13:01:59 +0530, Amit Kapila wrote:
> > > Okay, but if it crashes before saving the persistency to permanent
> > > file and there remains a .tmp for this replication slot which it created
> > > during save of this persistency information, then also xmin will get
> > > lost, because during startup it will not consider such a slot.
> >
> > I can't follow here. If it crashes before it's marked persistent it'll
> > get deleted at startup (c.f. RestoreSlotFromDisk). And .tmp slots are
> > cleaned up at restart.
>
> Yes that's fine, the point I wanted to say here is that the flush
> of slot in CreateInitDecodingContext() wouldn't save xmin in all
> cases which is I think what it want to achieve.

It'll savely stored until a xact abort (will be deleted during cleanup),
PANIC crash (deleted during startup) or until the slot is marked as
persistent. Which is what we need.

Maybe this helps:
/*
* For logical decoding, it's extremely important that we never remove any
* data that's still needed for decoding purposes, even after a crash;
* otherwise, decoding will produce wrong answers. Ordinary streaming
* replication also needs to prevent old row versions from being removed
* too soon, but the worst consequence we might encounter there is
* unwanted query cancellations on the standby. Thus, for logical
* decoding, this value represents the latest xmin that has actually been
* written to disk, whereas for streaming replication, it's just the same
* as the persistent value (data.xmin).
*/
TransactionId effective_xmin;
TransactionId effective_catalog_xmin;

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services