Re: Sync Rep v17

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Sync Rep v17
Дата
Msg-id 1299098348.1974.3699.camel@ebony
обсуждение исходный текст
Ответ на Re: Sync Rep v17  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Sync Rep v17  (Andrew Dunstan <andrew@dunslane.net>)
Re: Sync Rep v17  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Sync Rep v17  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Sync Rep v17
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE deadlock with concurrent INSERT