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

Re: Synchronous commit not... synchronous?

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, 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 18:41:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 2 November 2012 16:27, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> It would be.  But you are not cancelling the commit, you are
>> *attempting* to cancel the commit.  The message you receive explains
>> to what extend your attempt succeeded.
> That is correct.
> It is possible to cancel the COMMIT, but only until it happens.
> If people want full two phase commit, that option exists also.

I see why it is implemented this way, but it's also still pretty
unsatisfying because it means that with cancellation requests clients
are in theory able to commit an unlimited number of transactions,
synchronous commit or no.

It's probably close enough for most purposes, but what would you think
about a "2PC-ish" mode at the physical (rather than logical/PREPARE
TRANSACTION) level, whereby the master would insist that its standbys
have more data written (or at least received...or at least sent) than
it has guaranteed flushed to its own xlog at any point?

This would be a nice invariant to have when dealing with a large
number of systems, allowing for the catching of some tricky bugs, that
standbys are always greater-than-or-equal-to the master's XLogPos.


In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2012-11-02 19:05:47
Subject: Re: Unresolved error 0xC0000409 on Windows Server
Previous:From: Matthew GerberDate: 2012-11-02 18:25:33
Subject: Unresolved error 0xC0000409 on Windows Server

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