Horton

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

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Markus Wanner <markus@bluegap.ch>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, MARK CALLAGHAN <mdcallag@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Andrew Dunstan <andrew@dunslane.net>, Aidan Van Dyk <aidan@highrise.ca>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-03-18T19:29:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Efficient transaction-controlled synchronous replication.

On Fri, 2011-03-18 at 20:19 +0100, Markus Wanner wrote:
> Simon,
> 
> On 03/18/2011 05:19 PM, Simon Riggs wrote:
> >>> Simon Riggs<simon@2ndQuadrant.com>  wrote:
> >>>> In PostgreSQL other users cannot observe the commit until an
> >>>> acknowledgement has been received.
> 
> On other nodes as well?  To me that means the standby needs to hold back
> COMMIT of an ACKed transaction, until receives a re-ACK from the master,
> that it committed the transaction there.  How else could the slave know
> when to commit its ACKed transactions?

We could do that easily enough, actually, if we wished.

Do we wish?

> > 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.
> 
> If you don't failover, how can the standby be ahead of the master, given
> it takes measures not to be during normal operation?
> 
> Eager to understand... ;-)
> 
> Regards
> 
> Markus

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