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

Re: Synchronous commit not... synchronous?

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 19:59:04
Message-ID: CAAZKuFZG1X0ww-YhXDaddZ=jRBDGR34mveajhETXn-33FC2r-Q@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-11-05 20:07:02
Subject: Re: Limiting the number of parameterized indexpaths created
Previous:From: Robert HaasDate: 2012-11-05 19:46:35
Subject: Re: Limiting the number of parameterized indexpaths created

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