From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep Design |
Date: | 2011-01-01 15:12:19 |
Message-ID: | 4D1F4453.50903@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/01/2011 03:15 PM, Robert Haas wrote:
> On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
> <stefan(at)kaltenbrunner(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2011-01-01 15:31:29 | Re: and it's not a bunny rabbit, either |
Previous Message | Robert Haas | 2011-01-01 15:00:46 | Re: and it's not a bunny rabbit, either |