Skip site navigation (1) Skip section navigation (2)

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

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, MARK CALLAGHAN <mdcallag(at)gmail(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-18 17:35:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
On Fri, Mar 18, 2011 at 4:33 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> The fundamental problem here is that once you update CLOG and flush
> the corresponding WAL record, there is no going backward.  You can
> hold the system in some intermediate state where the transaction still
> holds locks and is excluded from MVCC snapshots, but there's no way to
> back up.  So there are bound to be corner cases where the where the
> wait doesn't last as long as you want, and stuff leaks out around the
> edges.

I'm finding this whole idea of hiding the committed transaction until
the slave acks it kind of strange. It means there are times when the
slave is actually *ahead* of the master which would actually be kind
of hard to code against if you're trying to use the slave as a
possibly-not-up-to-date mirror.

I think promising that the COMMIT doesn't return until the transaction
and all previous transactions are replicated is enough. We don't have
to promise that nobody else will see it either. Those same
transactions eventually have to commit as well and if they want that
level of protection they can block waiting until they're replicated as
well which will imply that anything they depended on will be

This is akin to the synchronous_commit=off case where other
transactions can see your data as soon as you commit even before the
xlog is fsynced. If you have synchronous_commit mode enabled then
you'll block until your xlog is fsynced and that will implicitly mean
the other transactions you saw were also fsynced.


In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-03-18 17:50:16
Subject: Re: SSI bug?
Previous:From: Robert HaasDate: 2011-03-18 17:25:16
Subject: Re: Sync Rep and shutdown Re: Sync Rep v19

pgsql-committers by date

Next:From: Markus WannerDate: 2011-03-18 19:17:56
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Kevin GrittnerDate: 2011-03-18 16:48:57
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group