MIME-Version: 1.0
In-Reply-To: <4D83B54C.2030708@bluegap.ch>
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>
Date: Fri, 18 Mar 2011 17:08:11 -0400
Message-ID: <AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled
	synchronous replication.
From: Aidan Van Dyk <aidan@highrise.ca>
To: Markus Wanner <markus@bluegap.ch>
Cc: 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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 18, 2011 at 3:41 PM, Markus Wanner <markus@bluegap.ch> wrote:
> On 03/18/2011 08:29 PM, Simon Riggs wrote:
>> We could do that easily enough, actually, if we wished.
>>
>> Do we wish?
>
> I personally don't see any problem letting a standby show a snapshot
> before the master. =A0I'd consider it unneeded network traffic. =A0But th=
en
> again, I'm completely biased.

In fact, we *need* to have standbys show a snapshot before the master.

By the time the master acks the commit to the client, the snapshot
must be visible to all client connected to both the master and the
syncronous slave.

Even with just a single server postgresql cluster, other
clients(backends) can see the commit before the commiting client
receives the ACK.  Just that on a single server, the time period for
that is small.

Sync rep increases that time period by the length of time from when
the slave reaches the commit point in the WAL stream to when it's ack
of that point get's back to the wal sender.  Ideally, that ACK time is
small.

Adding another round trip in there just for a "go almost to $COMIT,
ok, now go to $COMMIT" type of WAL/ack is going to be pessimal for
performance, and still not improve the *guarentees* it can make.

It can only slightly reduce, but not eliminated that window where them
master has WAL that the slave doesn't, and without a complete
elimination (where you just switch the problem to be the slave has the
data that the master doesn't), you haven't changed any of the
guarantees sync rep can make (or not).

a.

--=20
Aidan Van Dyk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Create like a god,
aidan@highrise.ca =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 command like a king,
http://www.highrise.ca/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 work like a slave.