On 03/07/2011 09:02 AM, Heikki Linnakangas wrote:
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.
My worry is that the stricter definition is what many people will
expect, without reading the fine print.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
