On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote: > > 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.
I'm trying to follow along here. Wouldn't the same issue exist if one transaction is waiting for sync rep (synchronous_commit=on), and another is waiting for just a WAL flush (synchronous_commit=local)? I don't think that a synchronous_commit=off is required. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers