From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Sat, 01 Jan 2011 16:12:19 +0100
Message-ID: <4D1F4453.50903@kaltenbrunner.cc> (raw)
In-Reply-To: <AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: stefan@kaltenbrunner.cc, robertmhaas@gmail.com, jeff.janes@gmail.com, simon@2ndquadrant.com
Subject: Re: Sync Rep Design
In-Reply-To: <4D1F4453.50903@kaltenbrunner.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox