Re: Sync Rep v17 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Sync Rep v17
Date
Msg-id 1299098348.1974.3699.camel@ebony
Whole thread Raw
In response to Re: Sync Rep v17  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Sync Rep v17
Re: Sync Rep v17
Re: Sync Rep v17
List pgsql-hackers
On Wed, 2011-03-02 at 22:10 +0200, Heikki Linnakangas wrote:
> On 02.03.2011 21:48, Simon Riggs wrote:
> > On Wed, 2011-03-02 at 16:53 +0200, Heikki Linnakangas wrote:
> >> On 02.03.2011 12:40, Simon Riggs wrote:
> >>> allow_standalone_primary seems to need to be better through than it is
> >>> now, yet neither of us think its worth having.
> >>>
> >>> If the people that want it can think it through a little better then it
> >>> might make this release, but I propose to remove it from this current
> >>> patch to allow us to commit with greater certainty and fewer bugs.
> >>
> >> If you leave it out, then let's rename the feature to "semi-synchronous
> >> replication" or such. The point of synchronous replication is
> >> zero-data-loss, and you don't achieve that with allow_standalone_primary=on.
> >
> > The reason I have suggested leaving that parameter out is because the
> > behaviour is not fully specified and Yeb has reported cases that don't
> > (yet) make sense. If you want to fully specify it then we could yet add
> > it, assuming we have time.
> 
> Fair enough. All I'm saying is that if we end up shipping without that 
> parameter (implying allow_standalone_primary=on), we need to call the 
> feature something else. The GUCs and code can probably stay as it is, 
> but we shouldn't use the term "synchronous replication" in the 
> documentation, and release notes and such.

allow_standalone_primary=off means "wait forever". It does nothing to
reduce data loss since you can't replicate to a server that isn't there.

As we discussed it, allow_standalone_primary=off was not a persistent
state, so shutting down the database would simply leave the data
committed. Which gives the same problem, but implicitly.

Truly "synchronous" requires two-phase commit, which this never was. So
the absence or presence of the poorly specified parameter called
allow_standalone_primary should have no bearing on what we call this
feature.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Sync Rep v17
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE deadlock with concurrent INSERT