Stephen Frost wrote:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > > Last I paid attention to this, there was a clear way to disable the
> > > inclusion of postgresql.auto.conf in the postgresql.conf. If that's
> > > gone, then there is a serious problem. Administrators who manage their
> > > postgresql.conf (eg: through a CM system like puppet or chef..) must
> > > have a way to prevent other changes.
> >
> > Sigh, here we go again. I don't think you can disable postgresql.auto.conf
> > in the current code. As I recall, the argument was that it's harder to
> > diagnose problems if postgresql.auto.conf takes effect in some system
> > but not others.
>
> I don't buy this at all. What's going to be terribly confusing is to
> have config changes start happening for users who are managing their
> configs through a CM (which most should be..). ALTER SYSTEM is going to
> cause more problems than it solves.
I guess if you have two DBAs who don't talk to each other, and one
changes things through puppet and another through ALTER SYSTEM, it's
going to be confusing, yes.
> > I think if you want puppet or chef etc you'd add postgresql.auto.conf as
> > a config file in those systems, so that ALTER SYSTEM is reflected there.
>
> That's really a horrible, horrible answer. The DBA makes some change
> and then reloads remotely, only to have puppet or chef come along and
> change it back later? Talk about a recipe for disaster.
Are you saying puppet/chef don't have the concept that a file is to be
backed up and changes on it notified, but that direct changes to it
should not be allowed? That sounds, um, limited.
> The only reason I stopped worrying about the foolishness of ALTER SYSTEM
> was because it could be disabled. I'm very disappointed to hear that
> someone saw fit to remove that. I'll also predict that it'll be going
> back in for 9.5.
*shrug*
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
