Re: Few observations in replication slots related code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Few observations in replication slots related code
Date
Msg-id 20140613081517.GA20954@alap3.anarazel.de
Whole thread Raw
In response to Re: Few observations in replication slots related code  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Few observations in replication slots related code  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2014-06-13 13:01:59 +0530, Amit Kapila wrote:
> On Thu, Jun 12, 2014 at 12:45 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
> > On 2014-06-12 08:55:59 +0530, Amit Kapila wrote:
> > > Function pg_create_logical_replication_slot() is trying to
> > > save slot twice once during CreateInitDecodingContext() and
> > > then in ReplicationSlotPersist(), isn't it better if we can make
> > > it do it just once?
> >
> > Doesn't work here. In the first save it's not yet marked as persistent -
> > but we still need to safely reserve the xmin.
> 
> 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.
It's fine if the entire slot is lost if the server crashes too early -
we haven't yet returned sucess...

> > Yes. There's lots of ways to screw over your database by using
> > pg_resetxlog.
> 
> Thats right, trying to think if there could be any thing which
> won't even allow the server to get started due to replication slots
> after pg_resetxlog.  As per my current understanding, I don't think
> there is any such problem.

I'm not aware of any.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Quan Zongliang
Date:
Subject: Re: PL/pgSQL support to define multi variables once
Next
From: Michael Paquier
Date:
Subject: Re: PL/pgSQL support to define multi variables once