Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 1E1FA1337B90
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Sat,  1 Jan 2011 11:12:32 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 38222-06
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Sat,  1 Jan 2011 15:12:24 +0000 (UTC)
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 BD7F61337B88
	for <pgsql-hackers@postgresql.org>;
	Sat,  1 Jan 2011 11:12:24 -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 1PZ380-0002oC-RF; Sat, 01 Jan 2011 16:12:23 +0100
Message-ID: <4D1F4453.50903@kaltenbrunner.cc>
Date: Sat, 01 Jan 2011 16:12:19 +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: Robert Haas <robertmhaas@gmail.com>
CC: Jeff Janes <jeff.janes@gmail.com>, Simon Riggs <simon@2ndquadrant.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>
In-Reply-To: <AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com>
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/13
X-Sequence-Number: 177850

On 01/01/2011 03:15 PM, Robert Haas wrote:
> On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc>  wrote:
>> that is exactly my point - if have no guarantee that your SYNC standby is
>> actually sync there is no use for it being used in business cases that
>> require sync replication.
>> If we cannot support that usecase I would either like to see us restricting
>> to only one sync capable standby or by putting a big CAVEAT into the docs
>> saying that sync replication in pg only is a hint and not a guarantee that
>> might or might not be honored in the case of more than one standby.
>
> I think it's clear that different people want to different things.  I
> understand Simon's point, but I think the point Stefan and Jeff are
> making is equally valid.  I think the solution is:
>
> - Simon gets to implement his version first because he's writing the
> code.  If someone else writes the code then they get to pick.

fair point ;)

>
> - Whoever wants to make the other thing work can write a patch for that after.

yeah but I still would like to get a statement on why simon thinks that 
the design heikki and others have proposed for supporting multiple sync 
standby that are actually sync (and also supports semi-sync as his patch 
which i consider a degraded case of full sync).

if you take the syncronous_standbys=<list> thing as an example what 
about considering it as:

foo: sync capable standby
bar  sync capable standby
baz: sync capable standby

with

syncronous_standbys=<standbyname>:<sync required(bool)

syncronous_standbys=foo,bar,baz you get sems sync - whatever standby 
returns first causes the master to return as well (as in what simons 
patch does)
syncronous_standbys=foo:true,bar:true,baz - require at least foo and bar 
to reply before the master returns

** the syntax chosen ist just a random example and could be anything **


that one could as well be used to do other per standby configurations 
(timeouts, wait behaviour etc) or not only being a 
syncronous_standby=<list> thing but more a standby_list = <list> thingy 
that also includes async slaves (defaulting to * or whatever so 
everything is async with default settings unless anything else is specified)

>
> - 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.

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 :)
Anyway as long as sync rep is disabled by default I'm fine with that.


Stefan