On Tue, Oct 5, 2010 at 10:33 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, 2010-10-05 at 09:07 -0500, Kevin Grittner wrote: >> Simon Riggs <si...@2ndquadrant.com> wrote: >> > Robert Haas wrote: >> >> Simon Riggs <si...@2ndquadrant.com> wrote: >> >>> Josh Berkus wrote: >> >>>>>>> Quorum commit, even with configurable vote weights, can't >> >>>>>>> handle a requirement that a particular commit be replicated >> >>>>>>> to (A || B) && (C || D). >> >>>>>> Good point. >> >>> >> >>> Asking for quorum_commit = 3 would cover that requirement. >> >>> >> >>> Not exactly as requested, >> >> >> That's just not the same thing. >> > >> > In what important ways does it differ? >> >> When you have one server functioning at each site you'll block until >> you get a third machine back, rather than replicating to both sites >> and remaining functional. > > And that is so important a consideration that you would like to move > from one parameter in one file to a whole set of parameters, set > differently in 5 separate files?
I don't accept that this is the trade-off being proposed. You seem convinced that having the config all in one place on the master is going to make things much more complicated, but I can't see why. > Is it a common use case that people > have more than 3 separate servers for one application, which is where > the difference shows itself. Much of the engineering we are doing centers around use cases that are considerably more complex than what most people will do in real life. > Another check: does specifying replication by server in such detail mean > we can't specify robustness at the transaction level? If we gave up that > feature, it would be a great loss for performance tuning. No, I don't think it means that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
