On Thu, Jul 28, 2011 at 11:57 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> But should we rethink that? Your point that hot standby transactions on >>> a slave could see snapshots that were impossible on the parent was >>> disturbing. Should we look for a way to tie "transaction becomes >>> visible" to its creation of a commit WAL record? I think the fact that >>> they are not an indivisible operation is an implementation artifact, and >>> not a particularly nice one. > >> Well, I agree with you that it isn't especially nice, but it seems >> like a fairly intractable problem. Currently, the standby has no way >> of knowing in what order the transactions became visible on the >> master. > > Right, but if the visibility order were *defined* as the order in which > commit records appear in WAL, that problem neatly goes away. It's only > because we have the implementation artifact that "set my xid to 0 in the > ProcArray" is decoupled from inserting the commit record that there's > any difference.
Hmm, interesting idea. However, consider the scenario where some transactions are using synchronous_commit or synchronous replication, and others are not. If a transaction that needs to wait (either just for WAL flush, or for WAL flush and synchronous replication) inserts its commit record, and then another transaction with synchronous_commit=off comes along and inserts its commit record, the second transaction will have to block until the first transaction is done waiting. We can't make either transaction visible without making both visible, and we certainly can't acknowledge the second transaction to the client until we've made it visible. I'm not going to say that's so horrible we shouldn't even consider it, but it doesn't seem great, either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers