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

From Kevin Grittner
Subject Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date
Msg-id 4D8341BD020000250003BAB2@gw.wicourts.gov
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
List pgsql-hackers
> On 18.03.2011 16:52, Kevin Grittner wrote:
>> Simon Riggs<simon@2ndQuadrant.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@bluegap.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.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 2nd Level Buffer Cache
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.