Message-ID: <4D1F60B4.1060408@kaltenbrunner.cc>
Date: Sat, 01 Jan 2011 18:13:24 +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: Simon Riggs <simon@2ndQuadrant.com>
CC: Robert Haas <robertmhaas@gmail.com>, Jeff Janes <jeff.janes@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>	
	<4D1CEEAF.8050209@kaltenbrunner.cc>	<1293744235.1892.26478.camel@ebony>	
	<4D1D93F1.80602@kaltenbrunner.cc>	<1293791171.1892.36233.camel@ebony>	
	<AANLkTinq-Aii-6fG-QGXUGnkVUdy3rYt71kEb2aA9y7B@mail.gmail.com>	
	<4D1F3437.10503@kaltenbrunner.cc>	
	<AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com>	
	<4D1F4453.50903@kaltenbrunner.cc>
	<1293900957.1892.60412.camel@ebony>
In-Reply-To: <1293900957.1892.60412.camel@ebony>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/01/2011 05:55 PM, Simon Riggs wrote:
> On Sat, 2011-01-01 at 16:12 +0100, Stefan Kaltenbrunner wrote:
>
>> I still would like to get a statement on why simon thinks that
>> the design heikki and others have proposed
>
> I've explained in huge detail why I think what I think, nor avoided any
> technical issue.
>
> It appears to me there has been substantial confusion over alternatives,
> because of a misunderstanding about how synchronisation works. Requiring
> confirmation that standbys are in sync is *not* the same thing as them
> actually being in sync. Every single proposal made by anybody here on
> hackers that supports multiple standby servers suffers from the same
> issue: when the primary crashes you need to work out which standby
> server is ahead.

aaah that was exactly what I was after - so the problem is that when you 
have a sync standby it will technically always be "in front" of the 
master (because it needs to fsync/apply/whatever before the master).
In the end the question boils down to what is "the bigger problem" in 
the case of a lost master:

a) a transaction that was confirmed on the master but might not be on 
any of the surviving sync standbys (or you will never know if it is) - 
this is how I understand the proposal so far
b) a transaction that was not yet confirmed on the master but might have 
been applied on the surving standby before the desaster - this is what I 
understand "confirm from all sync standbys" could result in.

Spelled out that more clearly now makes me a bit reconsider on what I 
said before but I still wonder if ultimately we will have to provide 
both modes to satisfy different business requirements (a might provide 
the more accurate answer on average but b might at least provide a way 
to identify the "wild" transaction buy looking at additional data)


>
>
>> - The docs should not allege that either setup is preferable to the
>>> other, because there is not now and will never be consensus that this
>>> is in fact true.
>
> I remain hopeful that people will read what I have read and understand
> it. Having taken the trouble to do that publicly, my conscious is clear
> that I've done the very best to explain things and make it easy for
> users to avoid error. If I am prevented from putting sound advice into
> the docs, I'll not worry too much.
>
>
>> well I should think we need to clearly spell out everything that affects
>> reliability and if we only support semi-sync for more than 1 standby we
>> have only that setup :)
>
> You can use sync rep with 1 or more standby servers.
>
> At the end of the day, I can't stop anyone from saying "What an idiot,
> he designed something that gave the same durability and availability as
> Oracle and MySQL do, yet with additional performance management
> features".

ok


Stefan