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

Kevin Grittner <kevin.grittner@wicourts.gov>

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

To: "Andrew Dunstan" <andrew@dunslane.net>, "Aidan Van Dyk" <aidan@highrise.ca>

Cc: "Simon Riggs" <simon@2ndquadrant.com>, "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.com>, <pgsql-hackers@postgresql.org>

Date: 2011-03-07T15:13:46Z

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

Andrew Dunstan <andrew@dunslane.net> wrote:

>   Synchronous replication - guarantees "zero data loss" by the
>   means of atomic write operation, i.e. write either completes on
>   both sides or not at all.

So far, so good.

>   Write is not considered complete until acknowledgement by both
>   local and remote storage.

OK, *if* we want to live up to this definition, we don't seem to
have that part covered.  Of course, since the connection is broken
during the hypothetical crash, it seems hard to acknowledge it on
recovery, and short of 2PC I don't see how we roll it back.  About
the best we could do is somehow have explicit logging of the
disposition of unacknowledged commit requests upon recovery, and
consider logging of success to be "acknowledgement".  Is this
logging provided by other databases with "synchronous replication"
features?

-Kevin