Re: Turning recovery.conf into GUCs - Mailing list pgsql-hackers

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> 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.

It's not DBAs, that's the point..  You have sysadmins who manage the
system configs (things like postgresql.conf) and you have DBAs whose
only access to the system is through 5432.  This seperation of
responsibilities is very common, in my experience at least, and
conflating the two through ALTER SYSTEM is going to cause nothing but
problems.  There had been a way to keep that seperation by simply
disabling the postgresql.auto.conf, but that's now been removed.

> > > 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.

Of course they can but that's completely missing the point.  The
postgresql.conf file is *already* managed in puppet or chef in a *lot*
of places.  We're removing the ability to do that and reverting to a
situation where auditing has to be done instead.  That's a regression,
not a step forward.

> > 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*

... and I'll continue to argue against anything which requires
postgresql.auto.conf to be hacked to work (as was proposed on this
thread..).
Thanks,
    Stephen