Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date
Msg-id 4D74E584.7080409@enterprisedb.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
List pgsql-hackers
On 07.03.2011 15:30, Andrew Dunstan wrote:
> 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?

The guarantee we have now with synchronous_replication=on is that when 
the server acknowledges a commit to the client (ie. when COMMIT command 
returns), the transaction is safely flushed to disk on the master and at 
least one synchronous standby server.

What you don't get is a guarantee on what happens to transactions that 
were not acknowledged to the client. For example, if you pull the power 
plug, the transaction that was just being committed might be committed 
on the master, but not yet on the standby.

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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sync Rep v19
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.