Re: Synchronous commit not... synchronous?

On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina <daniel@heroku.com> wrote:
> 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.

Right, but what you're complaining about is that you can't cancel the
transaction after beginning to make it 2-safe.

> 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.

Well, feel free to make a suggestion.  We could have a mode where a
commit, once initiated, is not user-cancellable, but that doesn't seem
like a usability improvement to me.  That just forces somebody to
bounce the server in a situation where it isn't necessary.  The
warning is not unclear about what has happened.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company