On Thu, 2010-09-23 at 16:09 -0400, Robert Haas wrote:
> On Thu, Sep 23, 2010 at 3:46 PM, Simon Riggs <simon@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.comPostgreSQL Development, 24x7 Support, Training and Services
