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

Re: Synchronous commit not... synchronous?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: 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-02 14:51:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Nov 2, 2012 at 4:42 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Btw, I believe that this is correct behavior, because in Peter's case the
>> manual command gets the priority on the value of synchronous_commit, no?
>> If anybody thinks that I am wrong, feel free to argue on that of course...
> The idea of canceling a COMMIT statement causing a COMMIT seems pretty
> strange to me.
> I would also not expect a cancelled INSERT statement to INSERT, as
> seems would happen by applying the same rules in the
> autocommit/implicit commit case here.

So how should we handle the case where cancel request or SIGINT arrives
while COMMIT is waiting for its WAL to be replicated to the standby? It's hard
to rollback the COMMIT because its WAL has already been flushed to
the disk locally. You think that we should prevent COMMIT at that state
from being canceled?


Fujii Masao

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2012-11-02 14:56:08
Subject: Re: Extensions Documentation
Previous:From: Dimitri FontaineDate: 2012-11-02 14:50:35
Subject: Re: [9.1] 2 bugs with extensions

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