On Fri, 2010-09-17 at 21:32 +0200, Dimitri Fontaine wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote: > >> According to what I heard, some people want to guarantee that all the > >> transactions are *always* written in *all* the synchronous standbys. > > > > You don't need standby registration at all. You can do that with a > > single parameter, already proposed: > > > > quorum_commit = N. > > I think you also need another parameter to control the behavior upon > timeout. You received less than N votes, now what? You're current idea > seems to be COMMIT, Aidan says ROLLBACK, and I say that's to be a GUC > set at the transaction level.
I've said COMMIT with no option because I believe that we have only two choices: commit or wait (perhaps forever), and IMHO waiting is not good. We can't ABORT, because we sent a commit to the standby. If we abort, then we're saying the standby can't ever come back because it will have received and potentially replayed a different transaction history. I had some further thoughts around that but you end up with the byzantine generals problem always. Waiting might sound attractive. In practice, waiting will make all of your connections lock up and it will look to users as if their master has stopped working as well. (It has!). I can't imagine why anyone would ever want an option to select that; its the opposite of high availability. Just sounds like a serious footgun. Having said that Oracle offers Maximum Protection mode, which literally shuts down the master when you lose a standby. I can't say anything apart from "LOL". > As far as registration goes, I see no harm to have the master maintain a > list of known standby systems, of course, it's just maintaining that > list from the master that I don't understand the use case for. Yes, the master needs to know about all currently connected standbys. The only debate is what happens about ones that "ought" to be there. Given my comments above, I don't see the need. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
