Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id EF0D91337999 for ; Mon, 7 Mar 2011 11:03:18 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 03357-03 for ; Mon, 7 Mar 2011 15:03:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mail.postgresql.org (Postfix) with ESMTP id 8521B133798E for ; Mon, 7 Mar 2011 11:03:10 -0400 (AST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=gDkBpS8wh10A:10 a=8nJEP1OIZ-IA:10 a=qCTYjJJ2g1SgQhsHZAUATw==:17 a=KemSYLhRAAAA:8 a=8pif782wAAAA:8 a=iEi220B9LsGDWBhvAB8A:9 a=cpiyd8SDaGGup0STmvcA:7 a=aLJhz334G3uLfOBpwCWs9vwgeS8A:4 a=wPNLvfGTeEIA:10 a=IvWp0zEv-XEA:10 a=qCTYjJJ2g1SgQhsHZAUATw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.27.48.207 Received: from [98.27.48.207] ([98.27.48.207:41889] helo=[192.168.10.104]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 79/CF-19545-EA3F47D4; Mon, 07 Mar 2011 15:03:11 +0000 Message-ID: <4D74F3AE.9000802@dunslane.net> Date: Mon, 07 Mar 2011 10:03:10 -0500 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Aidan Van Dyk CC: Heikki Linnakangas , Simon Riggs , pgsql-hackers@postgresql.org 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.419 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, RCVD_IN_DNSWL_NONE=-0.0001, SARE_SPEC_REPLICA=0.72 X-Spam-Level: ** X-Archive-Number: 201103/469 X-Sequence-Number: 183719 On 03/07/2011 09:29 AM, Aidan Van Dyk wrote: > On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstan wrote: > >>> For me, that's enough to call it "synchronous replication". It provides a >>> useful guarantee to the client. But you could argue for an even stricter >>> definition, requiring atomicity so that if a transaction is not successfully >>> replicated for any reason, including crash, it is rolled back in the master >>> too. That would require 2PC. >>> >> My worry is that the stricter definition is what many people will expect, >> without reading the fine print. > They they are either already hosed or already using 2PC. > > This is about expectations. The thing that worries me is that the use of this term might cause some people NOT to use 2PC because they think they are getting an equivalent guarantee, when in fact they are not. And that's hardly unreasonable. Here for example is what wikipedia says : 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. Write is not considered complete until acknowledgement by both local and remote storage. cheers andrew