On 01/01/2011 03:15 PM, Robert Haas wrote:
On Sat, Jan 1, 2011 at 9:03 AM, Stefan Kaltenbrunner
<ste...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
