From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Date: | 2011-03-07 14:29:04 |
Message-ID: | AANLkTinkzJ=UrLbThZy2KeQg+SjwYqj2r0mDomMwirB7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> For me, that's enough to call it "synchronous replication". It provides a
>> useful guarantee to the client. But you could argue for an even stricter
>> definition, requiring atomicity so that if a transaction is not successfully
>> replicated for any reason, including crash, it is rolled back in the master
>> too. That would require 2PC.
>>
>
> My worry is that the stricter definition is what many people will expect,
> without reading the fine print.
They they are either already hosed or already using 2PC.
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-03-07 14:55:11 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Previous Message | Andrew Dunstan | 2011-03-07 14:21:46 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-03-07 14:55:11 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Previous Message | Andrew Dunstan | 2011-03-07 14:21:46 | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |