Message-ID: <4D74E584.7080409@enterprisedb.com>
Date: Mon, 07 Mar 2011 16:02:44 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11
MIME-Version: 1.0
To: Andrew Dunstan <andrew@dunslane.net>
CC: Simon Riggs <simon@2ndQuadrant.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>
In-Reply-To: <4D74DDFA.70800@dunslane.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com