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

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>

To: "Simon Riggs" <simon@2ndquadrant.com>, "Robert Haas" <robertmhaas@gmail.com>

Cc: "Markus Wanner" <markus@bluegap.ch>, "Alvaro Herrera" <alvherre@commandprompt.com>, "Andrew Dunstan" <andrew@dunslane.net>, "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.com>, "MARK CALLAGHAN" <mdcallag@gmail.com>, "Aidan Van Dyk" <aidan@highrise.ca>, "pgsql-hackers" <pgsql-hackers@postgresql.org>

Date: 2011-03-18T21:24:03Z

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

Robert Haas <robertmhaas@gmail.com> wrote:

> Since the current solution is intended to support data-loss-free
> failover, but NOT to guarantee a consistent view of the world from
> a SQL level, I doubt it's worth paying any price for this.

Well, that brings us back to the question of why we would want to
suppress the view of the data on the master until the replica
acknowledges the commit.  It *is* committed on the master, we're
just holding off on telling the committer about it until we can
honor the guarantee of replication.  If it can be seen on the
replica before the committer get such acknowledgment, why not on the
master?

-Kevin