Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>, pgsql-hackers@postgresql.org
Date: 2011-03-07T13:30:34Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Efficient transaction-controlled synchronous replication.
- a8a8a3e09652 9.1.0 cited
On 03/07/2011 02:29 AM, Heikki Linnakangas wrote: > On 07.03.2011 01:28, Simon Riggs wrote: >> On Sun, 2011-03-06 at 18:09 -0500, Andrew Dunstan wrote: >>> >>> On 03/06/2011 05:51 PM, Simon Riggs wrote: >>>> Efficient transaction-controlled synchronous replication. >>> >>> I'm glad this is in, but I thought we agreed NOT to call it >>> "synchronous >>> replication". >> >> The discussion on the thread was that its not sync rep unless we have >> the strictest guarantees. We have the strictest guarantees, so it >> qualifies as sync rep. > > What do you mean by "strictes guarantees"? > > I don't see allow_synchronous_standby setting in the committed patch. > I presume you didn't make allow_synchronous_standby=off the default > behavior. Also, the documentation that describes this as two-safe > replication and claims that "the only possibility that data can be > lost is if both the primary and the standby suffer crashes at the same > time" needs big fat caveats to clarify that this doesn't actually > achieve those guarantees. > > Please change the name. > Previously, Simon said: > Truly "synchronous" requires two-phase commit, which this never was. So I too am confused about how it's now become "truly synchronous". Are we saying this give the same or better guarantees than a 2PC setup? cheers andrew