On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Daniel Farina: >> The idea of canceling a COMMIT statement causing a COMMIT seems pretty >> strange to me. > > Canceling commits is inherently racy, so I'm not sure if this behavior > so strange after all.
Yeah. You can't make the local fsync() and the remote fsync() happen at exactly the same moment in time. No implementation can do that, anywhere, ever. Our implementation happens to require the local fsync() to always be done first. With sufficient smarts, that could possibly be relaxed to allow them to run concurrently (if after a crash the master tried to fetch remotely committed WAL from its slave), but you still have the possibility that one fsync gets done and the other does not, and that would actually allow more weird edge cases than we have now - the main argument for it is performance. And because of the way our WAL stream works, once the commit record is fsync'd, it's too late to get cold feet. I daresay that will be true in any system, too. Once the local commit record hits the disk, the absolute best you could do, even theoretically, is *try* to take it back. And you had better be prepared for that to fail, because the system might crash or the take-back write might itself fail. Atomicity in a distributed system is not an easy problem. -- 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