On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <fw@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