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

From Simon Riggs
Subject Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date
Msg-id 1300465171.18619.15193.camel@ebony
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.
Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
List pgsql-hackers
On Fri, 2011-03-18 at 17:47 +0200, Heikki Linnakangas wrote:
> 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.  If we do that and MySQL doesn't, we
> > definitely don't want to use the same terminology they do, which
> > would imply the same behavior.
> 
> 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.

No, only in the case where you choose not to failover to the standby
when you crash, which would be a fairly strange choice after the effort
to set up the standby. In a correctly configured and operated cluster
what I say above is fully correct and needs no addendum.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

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