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@2ndquadrant.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
neededfor 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
encounterthere is * unwanted query cancellations on the standby.  Thus, for logical * decoding, this value represents
thelatest xmin that has actually been * written to disk, whereas for streaming replication, it's just the same * as the
persistentvalue (data.xmin). */TransactionId effective_xmin;TransactionId effective_catalog_xmin;
 


Greetings,

Andres Freund

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