Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id C0C861337B4E for ; Mon, 7 Mar 2011 10:21:54 -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 39506-04 for ; Mon, 7 Mar 2011 14:21:47 +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 313671337B58 for ; Mon, 7 Mar 2011 10:21:47 -0400 (AST) X-Authority-Analysis: v=1.1 cv=tLsyj04/L/SH/N6p42ldY6jXDYWe4pX5hAm6uRA1LKo= c=1 sm=0 a=gDkBpS8wh10A:10 a=IkcTkHD0fZMA:10 a=qCTYjJJ2g1SgQhsHZAUATw==:17 a=g-TFBtCDivyPuNZIP-8A:9 a=NuiEKcRpOMJOaEQm58UA:7 a=Hy1g5keti37x5w8vWs4nj7TXjpYA:4 a=QEXdDO2ut3YA: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:55219] helo=[192.168.10.104]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id CD/5D-05134-BF9E47D4; Mon, 07 Mar 2011 14:21:47 +0000 Message-ID: <4D74E9FA.7070202@dunslane.net> Date: Mon, 07 Mar 2011 09:21:46 -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: Heikki Linnakangas CC: 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> In-Reply-To: <4D74E584.7080409@enterprisedb.com> Content-Type: text/plain; charset=UTF-8; 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/466 X-Sequence-Number: 183716 On 03/07/2011 09:02 AM, Heikki Linnakangas wrote: > On 07.03.2011 15:30, Andrew Dunstan wrote: >> Previously, Simon said: >> >>> Truly "synchronous" requires two-phase commit, which this never was. >> >> So I too am confused about how it's now become "truly synchronous". Are >> we saying this give the same or better guarantees than a 2PC setup? > > The guarantee we have now with synchronous_replication=on is that when > the server acknowledges a commit to the client (ie. when COMMIT > command returns), the transaction is safely flushed to disk on the > master and at least one synchronous standby server. > > What you don't get is a guarantee on what happens to transactions that > were not acknowledged to the client. For example, if you pull the > power plug, the transaction that was just being committed might be > committed on the master, but not yet on the standby. > > 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. cheers andrew