Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
| От | Andrew Dunstan |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
| Дата | |
| Msg-id | 4D74DDFA.70800@dunslane.net обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Ответы |
Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled
synchronous replication.
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: