Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 266C61337B83
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 18 Mar 2011 18:24:25 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 49969-05
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 18 Mar 2011 21:24:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by mail.postgresql.org (Postfix) with ESMTP id 703621337999
	for <pgsql-hackers@postgresql.org>;
	Fri, 18 Mar 2011 18:24:14 -0300 (ADT)
Received: from Courts-MTA by gw.wicourts.gov
	with Novell_GroupWise; Fri, 18 Mar 2011 16:24:13 -0500
Message-Id: <4D838723020000250003BAFB@gw.wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 8.0.1 
Date: Fri, 18 Mar 2011 16:24:03 -0500
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>
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>
	<AANLkTinaE8pKZ5RyVShF8ZwDF2+GGQ1bZ_Y-jfO2rLAK@mail.gmail.com>
In-Reply-To: <AANLkTinaE8pKZ5RyVShF8ZwDF2+GGQ1bZ_Y-jfO2rLAK@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=2.409 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: **
X-Archive-Number: 201103/1172
X-Sequence-Number: 184422

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