Re: Sync Rep Design - Mailing list pgsql-hackers

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