Skip site navigation (1) Skip section navigation (2)

Re: Synchronous commit not... synchronous?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Florian Weimer <fw(at)deneb(dot)enyo(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous commit not... synchronous?
Date: 2012-11-05 21:19:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <fw(at)deneb(dot)enyo(dot)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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-11-05 21:21:21
Subject: Re: Deprecations in authentication
Previous:From: Palle GirgensohnDate: 2012-11-05 21:16:39
Subject: Re: alter table tablename add column - breaks pl/pgsql function returns tablename

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group