Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id E9F6D1337B39
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Sun,  2 Jan 2011 12:54:42 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 63916-04; Sun,  2 Jan 2011 16:54:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8])
	by mail.postgresql.org (Postfix) with SMTP id B06891337B34;
	Sun,  2 Jan 2011 12:54:34 -0400 (AST)
Received: from source ([209.85.215.171]) (using TLSv1) by
	exprod7ob118.postini.com ([64.18.6.12]) with SMTP
	ID DSNKTSCtyQ+9RkWfY3ukJK0EJh4SfwIiGxov@postini.com;
	Sun, 02 Jan 2011 08:54:35 PST
Received: by eyg5 with SMTP id 5so5992794eyg.2
	for <multiple recipients>; Sun, 02 Jan 2011 08:54:32 -0800 (PST)
Received: by 10.213.26.7 with SMTP id b7mr11139532ebc.29.1293987271960;
	Sun, 02 Jan 2011 08:54:31 -0800 (PST)
Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi
	[88.195.122.240])
	by mx.google.com with ESMTPS id t50sm14060245eeh.18.2011.01.02.08.54.30
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Sun, 02 Jan 2011 08:54:30 -0800 (PST)
Message-ID: <4D20ADC5.7070804@enterprisedb.com>
Date: Sun, 02 Jan 2011 18:54:29 +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: Simon Riggs <simon@2ndQuadrant.com>
CC: Robert Haas <robertmhaas@gmail.com>,
	Hannu Krosing <hannu@2ndquadrant.com>,
	greg@2ndquadrant.com, Josh Berkus <josh@postgresql.org>,
	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>
	<4D1DAB14.5000800@enterprisedb.com>	
	<1293796137.1892.37313.camel@ebony>
	<4D1DCF5A.7070808@enterprisedb.com>	
	<4D1E4897.1050400@2ndquadrant.com>
	<1293882875.1892.56143.camel@ebony>	
	<AANLkTi=yYKvRCvfTprbj=jQDVMrDKUMcate=vCaQobSi@mail.gmail.com>
	<1293975673.2090.464.camel@ebony>
In-Reply-To: <1293975673.2090.464.camel@ebony>
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=-4.2 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	RCVD_IN_DNSWL_MED=-2.3
X-Spam-Level: 
X-Archive-Number: 201101/80
X-Sequence-Number: 177917

On 02.01.2011 15:41, Simon Riggs wrote:
> On Sat, 2011-01-01 at 23:36 -0500, Robert Haas wrote:
>> On Sat, Jan 1, 2011 at 6:54 AM, Simon Riggs<simon@2ndquadrant.com>  wrote:
>>> Yes, working out the math is a good idea. Things are much clearer if we
>>> do that.
>>>
>>> Let's assume we have 98% availability on any single server.
>>>
>>> 1. Having one primary and 2 standbys, either of which can acknowledge,
>>> and we never lock up if both standbys fail, then we will have 99.9992%
>>> server availability. (So PostgreSQL hits "5 Nines", with data
>>> guarantees). ("Maximised availability")
>>
>> I don't agree with this math. ...(snip by Simon)... 99.96%.
>
> OK, so that is at least 99.96%. Cool.
>
> The key point here is not (1), but option (4).
>
> The approach advocated by Heikki and yourself gives us 94% availability.
> IMHO that is ridiculous, and I will not accept that as the *only* way
> forwards, for that reason, whoever advocates it or for how long they
> keep arguing. I do accept that some wish that as an option.

No-one is suggesting that to be the only option.

The "wait-for-all-to-ack" looks a lot less ridiculous if you also 
configure a timeout and don't wait for disconnected standbys. I'm not 
sure what the point of such a timeout in general is, but people have 
requested that. Also, setting synchronous_standbys="room1, room2" 
doesn't necessarily mean that you have just two standby servers, room1 
and room2 might both represent a group of servers.

I believe we all agree that there's different use cases that require 
different setups. Both "first-past-the-post" and "wait-for-all-to-ack" 
have their uses. There's no point in arguing over which is better.

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