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

From Stephen Frost
Subject Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs
Date
Msg-id 20141124203139.GY28859@tamriel.snowman.net
Whole thread Raw
In response to Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
* Josh Berkus (josh@agliodbs.com) wrote:
> On 11/24/2014 07:29 AM, Stephen Frost wrote:
> >> > > > 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.
>
> The main reason why disabling auto.conf was found not to be worthwhile
> is that anyone with superuser rights can *already* change the config by
> using ALTER DATABASE and ALTER ROLE, and that's a LOT less auditable
> than pg.auto.conf is.  Heck, we don't even have a good system view for
> SET parameters on DB objects.

If this was accurate, we wouldn't have any need for ALTER SYSTEM.

They *can't* make certain configuration changes which is why ALTER
SYSTEM was put into place to begin with.  Those pieces are also,
generally speaking, what's needed to get the database started and which
control authentication (and possibly authorization to connect).  As I've
pointed out before, we'll end up with DBAs making changes which break
the system from starting and they can't properly test that change nor do
anything about it when the DB can no longer start, and the sysadmins
will be extremely confused and, worse, will have zero clue that this
'auto.conf' thing even exists or where the config is coming from that's
preventing the DB from starting.  At least when postgresql.auto.conf was
explicitly in the top-level postgresql.conf, there was a hope that
they'd realize there's another config file in play (and figure out how
to disable it to get the system back online..) and now we haven't even
got that.

I agree that it'd be nice to have a better view of what has been set
using ALTER DATABASE and ALTER ROLE, but nothing here makes me feel any
differently about ALTER SYSTEM.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: postgresql.auto.conf comments
Next
From: Adam Brightwell
Date:
Subject: Role Attribute Bitmask Catalog Representation