* Fujii Masao <masao.fujii@gmail.com> [100721 03:49]:
> >> The patch provides quorum parameter in postgresql.conf, which
> >> specifies how many standby servers transaction commit will wait for
> >> WAL records to be replicated to, before the command returns a
> >> "success" indication to the client. The default value is zero, which
> >> always doesn't make transaction commit wait for replication without
> >> regard to replication_mode. Also transaction commit always doesn't
> >> wait for replication to asynchronous standby (i.e., replication_mode
> >> is set to async) without regard to this parameter. If quorum is more
> >> than the number of synchronous standbys, transaction commit returns
> >> a "success" when the ACK has arrived from all of synchronous standbys.
> >
> > There should be a way to specify "wait for *all* connected standby servers
> > to acknowledge"
>
> Agreed. I'll allow -1 as the valid value of the quorum parameter, which
> means that transaction commit waits for all connected standbys.
Hm... so if my 1 synchronouse standby is operatign normally, and quarum
is set to 1, I'll get what I want (commit waits until it's safely on both
servers). But what happens if my standby goes bad. Suddenly the quarum
setting is ignored (because it's > number of connected standby
servers?) Is there a way for me to not allow any commits if the quarum
setting number of standbies is *not* availble? Yes, I want my db to
"halt" in that situation, and yes, alarmbells will be ringing...
In reality, I'm likely to run 2 synchronous slaves, with quarum of 1.
So 1 slave can fail an dI can still have 2 going. But if that 2nd slave
ever failed while the other was down, I definately don't want the master
to forge on ahead!
Of course, this won't be for everyone, just as the current "just
connected standbys" isn't for everything either...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.