Message-ID: <4D89A0D1.4030601@bluegap.ch>
Date: Wed, 23 Mar 2011 08:27:13 +0100
From: Markus Wanner <markus@bluegap.ch>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Aidan Van Dyk <aidan@highrise.ca>, Simon Riggs <simon@2ndquadrant.com>,
	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>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled
	synchronous replication.
References: <E1PwMns-00047O-UU@gemulon.postgresql.org>
	<4D741441.2090704@dunslane.net>	<1299454125.1696.6138.camel@ebony>
	<4D74896C.5030402@enterprisedb.com>	<4D74DDFA.70800@dunslane.net>
	<4D74E584.7080409@enterprisedb.com>	<4D74E9FA.7070202@dunslane.net>
	<AANLkTinkzJ=UrLbThZy2KeQg+SjwYqj2r0mDomMwirB7@mail.gmail.com>
	<4D74F3AE.9000802@dunslane.net>	<4D74FDEC.5040406@enterprisedb.com>
	<4D74FF15.1070804@dunslane.net>	<1299513979-sup-1987@alvh.no-ip.org>
	<4D832571.5030808@bluegap.ch>
	<AANLkTi=B+cWE-pQJQM=zoA9=Zr25W7zPPMFvvBe11O4E@mail.gmail.com>
	<1300457958.18619.13780.camel@ebony>
	<4D832B4D020000250003BA98@gw.wicourts.gov>
	<4D837EA2.2070205@enterprisedb.com>	<1300465171.18619.15193.camel@ebony>
	<4D83B02A.5090105@bluegap.ch>	<1300476590.18619.18115.camel@ebony>
	<4D83B54C.2030708@bluegap.ch>
	<AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com>
	<AANLkTi=bD6iWZNggors9ooG-ZjXwxy6b=DPMWf160WNO@mail.gmail.com>
In-Reply-To: <AANLkTi=bD6iWZNggors9ooG-ZjXwxy6b=DPMWf160WNO@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/22/2011 09:33 PM, Robert Haas wrote:
> We might have a version of synchronous replication that works this way
> some day, but it's not the version were shipping with 9.1.  The slave
> acknowledges the WAL records when they hit the disk (i.e. fsync) not
> when they are applied; WAL apply can lag arbitrarily.  The point is to
> guarantee clients that the WAL is on disk somewhere and that it will
> be replayed in the event of a failover.  Despite the fact that this
> doesn't work as you're describing, it's a useful feature in its own
> right.

In that sense, our approach may be more synchronous than most others,
because after the ACK is sent from the slave, the slave still needs to
apply the transaction data from WAL before it gets visible, while the
master needs to wait for the ACK to arrive at its side, before making it
visible there.

Ideally, these two latencies (disk seek and network induced) are just
about equal.  But of course, there's no such guarantee.  So whenever one
of the two is off by an order of magnitude or two (by use case or due to
a temporary overload), either the master or the slave may lag behind the
other machine.

What pleases me is that the guarantee from the slave is somewhat similar
to Postgres-R's: with its ACK, the receiving node doesn't guarantee the
transaction *is* applied locally, it just guarantees that it *will* be
able to do so sometime in the future.  Kind of a mind twister, though...

Regards

Markus