* Fujii Masao <masao.fu...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
