Robert Haas <robertmh...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
