Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id AF81A1337B50
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Sat,  1 Jan 2011 12:37:27 -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 52266-05; Sat,  1 Jan 2011 16:37:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from cronos.madness.at (madness.at [217.196.146.217])
	by mail.postgresql.org (Postfix) with ESMTP id 365B81337B5B;
	Sat,  1 Jan 2011 12:37:19 -0400 (AST)
Received: from gatekeeper.kaltenbrunner.cc ([83.215.243.9]
 helo=[192.168.8.22])
	by cronos.madness.at with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <stefan@kaltenbrunner.cc>)
	id 1PZ4SA-0004VO-0O; Sat, 01 Jan 2011 17:37:16 +0100
Message-ID: <4D1F5838.8020509@kaltenbrunner.cc>
Date: Sat, 01 Jan 2011 17:37:12 +0100
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.15) Gecko/20101030 Iceowl/1.0b1 Icedove/3.0.10
MIME-Version: 1.0
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
CC: Simon Riggs <simon@2ndQuadrant.com>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	greg@2ndQuadrant.com, Josh Berkus <josh@postgresql.org>,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>, 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>	<1293822959.1892.43164.camel@ebony>
	<4D1F332A.90306@kaltenbrunner.cc> <m2ei8wy4ed.fsf@2ndQuadrant.fr>
In-Reply-To: <m2ei8wy4ed.fsf@2ndQuadrant.fr>
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=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201101/18
X-Sequence-Number: 177855

On 01/01/2011 05:28 PM, Dimitri Fontaine wrote:
> Stefan Kaltenbrunner<stefan@kaltenbrunner.cc>  writes:
>> well you keep saying that but to be honest I cannot really even see a
>> usecase for me - what is "only a random one of a set of servers is sync at
>> any time and I don't really know which one".
>
> It looks easy enough to get to know which one it is.  Surely the primary
> knows and could update something visible through a system view for
> users?  This as been asked for before and I was thinking there was a
> consensus on this.

well as jeff janes already said - anything that requires the master to 
still exist is not useful for a desaster. Consider the now often 
mentioned 2 sync standby scenario with one standby in the same location 
and one in a secondary location.
If you have a desaster(fire,water,explosion,admin fail,...) at the 
primary location and you have no access to either the master or the 
standby you will never be sure that the standby on the secondary 
location is actually "in sync" - it could be but you will never know if 
you lost that 1B$ invoice just commited on the master and the closeby 
standby and therefor confirmed to the client...
Most of my requirements have very hard requirements on the integrity of 
the data, very high requirements on the read-only availability and 
somewhat high requirements on the availability of a master for writes, 
but data integrity will always trump that.



Stefan