Message-ID: <4D1DAB14.5000800@enterprisedb.com>
Date: Fri, 31 Dec 2010 12:06:12 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10
MIME-Version: 1.0
To: Hannu Krosing <hannu@2ndquadrant.com>
CC: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>,
	Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>,
	pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
References: <1293729972.1892.23804.camel@ebony>
	<4D1CC47E.7050207@kaltenbrunner.cc>	<1293735853.1892.24886.camel@ebony>
	<AANLkTi=SvN2KQ1Tzh-tRKcXD0i2FyWFBbbR=kXXdepqN@mail.gmail.com>
	<4D1D8B2F.5070001@2ndquadrant.com>
In-Reply-To: <4D1D8B2F.5070001@2ndquadrant.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 31.12.2010 09:50, Hannu Krosing wrote:
> On 30.12.2010 22:27, Robert Haas wrote:
>> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs<simon@2ndquadrant.com>
>> wrote:
>>> synchronous_replication (boolean)
>>> Specifies whether transaction commit will wait for WAL records
>>> to be replicated before the command returns a "success"
>>> indication to the client.
>> The word "replicated" here could be taken to mean different things,
>> most obviously:
>>
>> - slave has received the WAL
>> - slave has fsync'd the WAL
>> - slave has applied the WAL
> Perhaps the level of "replication guarantee" should be decided on the
> slave side, by
> having a configuration parameter there
>
> report_as_replicated = received|written_to_disk|fsynced|applied
>
> for different types of hosts may have wildly different guarantees and
> performance
> parameters for these. One could envision a WAL-archive type "standby"
> which is
> there for data persistence only will and never "apply" WAL.

Agreed, it feels natural to specify when a piece of WAL is acknowledged 
in the standby.

Regarding the rest of the proposal, I would still prefer the UI 
discussed here:

http://archives.postgresql.org/message-id/4CAE030A.2060701@enterprisedb.com

It ought to be the same amount of work to implement, and provides the 
same feature set, but makes administration a bit easier by being able to 
name the standbys. Also, I dislike the idea of having the standby 
specify that it's a synchronous standby that the master has to wait for. 
Behavior on the master should be configured on the master.

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