On Wed, 2011-03-02 at 16:16 -0500, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On Wed, 2011-03-02 at 22:10 +0200, Heikki Linnakangas wrote: > >> 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. > > This is irrelevant to the point. The point is that sync rep implies > that we will not *tell a client* its data is committed unless the commit > is down to disk in two places. I agree with the people saying that not > having this parameter makes it not real sync rep.
Depends what you think the point is. Your comments go exactly to *my* point which is that the behaviour I'm looking to commit maximises data durability *and* availability and is the real choice that people will make. Claiming it "isn't real" will make people scared of it, when its actually what they have been waiting for. There is nothing half-arsed or unreal about what is being delivered. Let's not get hung up on textbook definitions, lets do the useful thing. And to repeat, I am not against the other way. It has its place, in a few cases. And I'm not against including it in this release either, given we have a good definition. -- 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
