Re: Sync Rep v17

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Sync Rep v17
Date: 2011-03-02 20:39:08
Message-ID: 1299098348.1974.3699.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-03-02 20:41:43 Re: ALTER TABLE deadlock with concurrent INSERT
Previous Message Joshua D. Drake 2011-03-02 20:36:48 Re: Sync Rep v17