Robert Haas <robertmhaas@gmail.com> wrote:
> Having transactions become visible in the same order on the master
> and the standby is very appealing, but I'm pretty well convinced
> that allowing commits to become visible before they've been
> durably committed is throwing the "D" an ACID out the window. If
> synchronous_commit is off, sure, but otherwise...
It has been durably committed on the master, but not on the
supposedly synchronous copy; so it's not so much through out the "D"
in "ACID" as throwing out the "synchronous" in "synchronous
replication". :-(
Unless I'm missing something we have a choice to make -- I see four
possibilities (already mentioned on this thread, I think):
(1) Transactions are visible on the master which won't necessarily
be there if a meteor takes out the master and you need to resume
operations on the replica.
(2) An asynchronous commit must block behind any pending
synchronous commits if synchronous replication is in use.
(3) Transactions become visible on the replica in a different order
than they became visible on the master.
(4) We communicate acceptable snapshots to the replica to make the
order of visibility visibility match the master even when that
doesn't match the order that transactions returned from commit.
I don't see how we can accept (1) and call it synchronous
replication. I'm pretty dubious about (3), because we don't even
have Snapshot Isolation on the replica, really. Is (3) where we're
currently at? An advantage of (4) is that on the replica we would
get the same SI behavior at Repeatable Read that exists on the
master, and we could even use the same mechanism for SSI to provide
Serializable isolation on the replica.
I (predictably) like (4) -- even though it's a lot of work....
-Kevin