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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers