On Tue, Oct 5, 2010 at 10:46 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote: >> >> >> >> 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. > > But it is not "all in one place" because the file needs to be different > on 5 separate nodes. Which *does* make it more complicated than the > alternative is a single parameter, set the same everywhere.
Well, you only need to have the file at all on nodes you want to fail over to. And aren't you going to end up rejiggering the config when you fail over anyway, based on what happened? I mean, suppose you have three servers and you require sync rep to 2 slaves. If the master falls over and dies, it seems likely you're going to want to relax that restriction. Or suppose you have three servers and you require sync rep to 1 slave. The first time you fail over, you're going to probably want to leave that config as-is, but if you fail over again, you're very likely going to want to change it. This is really the key question for me. If distributing the configuration throughout the cluster meant that we could just fail over and keep on trucking, that would be, well, really neat, and a very compelling argument for the design you are proposing. But since that seems impossible to me, I'm arguing for centralizing the configuration file for ease of management. -- 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
