On Fri, Mar 18, 2011 at 4:33 PM, Robert Haas <robertmh...@gmail.com> wrote: > The fundamental problem here is that once you update CLOG and flush > the corresponding WAL record, there is no going backward. You can > hold the system in some intermediate state where the transaction still > holds locks and is excluded from MVCC snapshots, but there's no way to > back up. So there are bound to be corner cases where the where the > wait doesn't last as long as you want, and stuff leaks out around the > edges.
I'm finding this whole idea of hiding the committed transaction until the slave acks it kind of strange. It means there are times when the slave is actually *ahead* of the master which would actually be kind of hard to code against if you're trying to use the slave as a possibly-not-up-to-date mirror. I think promising that the COMMIT doesn't return until the transaction and all previous transactions are replicated is enough. We don't have to promise that nobody else will see it either. Those same transactions eventually have to commit as well and if they want that level of protection they can block waiting until they're replicated as well which will imply that anything they depended on will be replicated. This is akin to the synchronous_commit=off case where other transactions can see your data as soon as you commit even before the xlog is fsynced. If you have synchronous_commit mode enabled then you'll block until your xlog is fsynced and that will implicitly mean the other transactions you saw were also fsynced. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers