Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 72E6E1337C04 for ; Fri, 18 Mar 2011 10:40:43 -0300 (ADT) 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 35360-01-5 for ; Fri, 18 Mar 2011 13:40:35 +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 8CB301337C05 for ; Fri, 18 Mar 2011 10:40:35 -0300 (ADT) Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Fri, 18 Mar 2011 08:40:23 -0500 Message-Id: <4D831A76020000250003BA82@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 18 Mar 2011 08:40:22 -0500 From: "Kevin Grittner" To: "Markus Wanner" , "MARK CALLAGHAN" Cc: "Simon Riggs" , "Alvaro Herrera" , "Andrew Dunstan" , "Heikki Linnakangas" , "Aidan Van Dyk" , "pgsql-hackers" Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. References: <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> <4D74F3AE.9000802@dunslane.net> <4D74FDEC.5040406@enterprisedb.com> <4D74FF15.1070804@dunslane.net> <1299513979-sup-1987@alvh.no-ip.org> <4D832571.5030808@bluegap.ch> In-Reply-To: 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/1117 X-Sequence-Number: 184367 MARK CALLAGHAN wrote: > Markus Wanner wrote: >> Google invented the term "semi-syncronous" for something that's >> essentially the same that we have, now, I think. However, I full >> heartedly hate that term (based on the reasoning that there's no >> semi-pregnant, either). To be fair, what we're considering calling semi-synchronous is something which tries to stay in synchronous mode but switches out of it when necessary to meet availability targets. Your analogy doesn't match up at all well -- at least without getting really ugly. > We didn't invent the term, we just implemented something that > Heikki Tuuri briefly described, for example: > http://bugs.mysql.com/bug.php?id=7440 > > In the Google patch and official MySQL version, the sequence is: > 1) commit on master > 2) wait for slave to ack > 3) return to user > > After step 1 another user on the master can observe the commit and > the following is possible: > 1) commit on master > 2) other user observes that commit on master > 3) master blows up and a user observed a commit that never made it > to a slave > > I do not think this sequence should be possible in a sync > replication system. Then the only thing you would consider sync replication, as far as I can see, is two phase commit, which we already have. So your use case seems to be covered already, and we're trying to address other people's needs. The guarantee that some people are looking for is that a successful commit means that the data has been persisted on two separate servers. Others want to try for that, but are willing to compromise it for HA; in general I think they want to know when the guarantee is not there so they can take action to get back to a safer condition. -Kevin