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

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