On Thu, 2010-09-23 at 16:09 -0400, Robert Haas wrote: > On Thu, Sep 23, 2010 at 3:46 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > Well, its not at all hard to see how that could be configured, because I > > already proposed a simple way of implementing parameters that doesn't > > suffer from those problems. My proposal did not give roles to named > > standbys and is symmetrical, so switchovers won't cause a problem. > > I know you proposed a way, but my angst is all around whether it was > actually simple. I found it somewhat difficult to understand, so > possibly other people might have the same problem.
Let's go back to Josh's 12 server example. This current proposal requires 12 separate and different configuration files each containing many parameters that require manual maintenance. I doubt that people looking at that objectively will decide that is the best approach. We need to arrange a clear way for people to decide for themselves. I'll work on that. > > Earlier you argued that centralizing parameters would make this nice and > > simple. Now you're pointing out that we aren't centralizing this at all, > > and it won't be simple. We'll have to have a standby.conf set up that is > > customised in advance for each standby that might become a master. Plus > > we may even need multiple standby.confs in case that we have multiple > > nodes down. This is exactly what I was seeking to avoid and exactly what > > I meant when I asked for an analysis of the failure modes. > > If you're operating on the notion that no reconfiguration will be > necessary when nodes go down, then we have very different notions of > what is realistic. I think that "copy the new standby.conf file in > place" is going to be the least of the fine admin's problems. Earlier you argued that setting parameters on each standby was difficult and we should centralize things on the master. Now you tell us that actually we do need lots of settings on each standby and that to think otherwise is not realistic. That's a contradiction. The chain of argument used to support this as being a sensible design choice is broken or contradictory in more than one place. I think we should be looking for a design using the KISS principle, while retaining sensible tuning options. -- 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
