On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
I don't think there is a (unachievable) requirement of simultaneous
flush, only that two machines have flushed (or met whatever durability
criteria) strictly more than the position of the commit in question.
This mean some changes are written to some place once, but
acknowledging commit requires proof of two-safety.
I can see how in some corner cases this might cause orphaning of
synchronous standbys that write, but cannot acknowledge.
If the point of synchronous commit is to reach exact two-safety by
waiting a while for other agents to process data, it would seem that
the current model could use some less-invasive tweaking, as-is one can
succeed in an unbounded number of commits in a degenerate case.
--
fdr
