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

Markus Wanner <markus@bluegap.ch>

From: Markus Wanner <markus@bluegap.ch>

To: Kevin Grittner <Kevin.Grittner@wicourts.gov>

Cc: Simon Riggs <simon@2ndQuadrant.com>, MARK CALLAGHAN <mdcallag@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Andrew Dunstan <andrew@dunslane.net>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Aidan Van Dyk <aidan@highrise.ca>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2011-03-18T15:43:38Z

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 →

Efficient transaction-controlled synchronous replication.
- a8a8a3e09652 9.1.0 cited

On 03/18/2011 03:52 PM, Kevin Grittner wrote:
> Really?  I hadn't picked up on that.  That makes for a lot of
> complication on crash-and-recovery of a master

What complication do you have in mind here?

I think of it the opposite way (at least for Postgres, that is):
committing a transaction that's not acknowledged means having to revert
a (locally only) committed transaction if you want to use the current
data to recover to some cluster-agreed state.  (Of course, you can
always simply transfer the whole

If you don't commit the transaction before the ACK in the first place,
you don't have anything special to do upon recovery.

Regards

Markus Wanner