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

Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Markus Wanner" <markus(at)bluegap(dot)ch>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "MARK CALLAGHAN" <mdcallag(at)gmail(dot)com>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-18 16:27:57
Message-ID: 4D8341BD020000250003BAB2@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
> On 18.03.2011 16:52, Kevin Grittner wrote:
>> Simon Riggs<simon(at)2ndQuadrant(dot)com>  wrote:
>> 
>>> In PostgreSQL other users cannot observe the commit until an
>>> acknowledgement has been received.
>> 
>> Really?  I hadn't picked up on that.  That makes for a lot of
>> complication on crash-and-recovery of a master, but if we can
>> pull it off, that's really cool.
 
Markus Wanner <markus(at)bluegap(dot)ch> wrote:
 
> What complication do you have in mind here?
 
Basically, what Heikki addresses.  It has to be committed after
crash and recovery, and deal with replicas which may or may not have
been notified and may or may not have applied the transaction.
 
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
 
> To be clear: other users cannot observe the commit until standby 
> acknowledges it - unless the master crashes while waiting for the 
> acknowledgment. If that happens, the commit will be visible to
> everyone after recovery.
 
Right.  If other transactions cannot see the transaction before the
COMMIT returns, I was kinda assuming that this was the behavior,
because otherwise one or more replicas could be ahead of the master
after recovery, which would be horribly broken.  I agree that the
behavior which you describe is much better than allowing other
transactions to see the work of the pending COMMIT.
 
In fact, on further reflection, allowing other transactions to see
work before the committing transaction returns could lead to broken
behavior if that viewing transaction took some action based on the
that, the master crashed, recovery was done using a standby, and
that standby hadn't persisted the transaction.  So this behavior is
necessary for good behavior.  Even though that "perfect storm" of
events might be fairly rare, the difference in the level of
confidence in correctness is significant, and certainly something to
brag about.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-18 16:33:26
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Robert HaasDate: 2011-03-18 16:19:47
Subject: Re: 2nd Level Buffer Cache

pgsql-committers by date

Next:From: Robert HaasDate: 2011-03-18 16:33:26
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Simon RiggsDate: 2011-03-18 16:19:31
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

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