Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 600BB1337999
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon,  7 Mar 2011 11:14:03 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 47984-04
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon,  7 Mar 2011 15:13:55 +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 1907A133798E
	for <pgsql-hackers@postgresql.org>;
	Mon,  7 Mar 2011 11:13:54 -0400 (AST)
Received: from Courts-MTA by gw.wicourts.gov
	with Novell_GroupWise; Mon, 07 Mar 2011 09:13:55 -0600
Message-Id: <4D74A1CA020000250003B569@gw.wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 8.0.1 
Date: Mon, 07 Mar 2011 09:13:46 -0600
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>
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>
In-Reply-To: <4D74F3AE.9000802@dunslane.net>
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=0.109 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	FS_REPLICA=3.599, RCVD_IN_DNSWL_MED=-2.3, SARE_SPEC_REPLICA=0.72,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201103/471
X-Sequence-Number: 183721

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