On 2014-06-13 14:21:33 +0530, Amit Kapila wrote: > On Fri, Jun 13, 2014 at 1:45 PM, Andres Freund <and...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers