Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET
Date
Msg-id 20130805174937.GM2706@tamriel.snowman.net
Whole thread Raw
In response to Re: Unsafe GUCs and ALTER SYSTEM WAS: Re: ALTER SYSTEM SET  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
> Based on serving literally hundreds of clients, the below are the
> settings we change on client servers 50% or more of the time.  Other
> settings I touch maybe 10% of the time.  THese are also, in general, the
> settings which I modify when we create Puppet/Chef/Salt scripts for clients.

And that is actually half my point with all of this- these things are
often set by change management systems like puppet or chef and you can
be almost guaranteed that the folks running those pieces of the
infrastructure will be *very* unhappy if the DBA tries to adjust those
parameters independently because it'll almost certainly *not work*.  In
particular, that goes for things like listen_addresses and port, but
also shared_buffers, checkpoint_segments, wal_keep_segments, etc.

When it comes to things like the stats_file_directory, the admin will
need to be doing things on the host server anyway to set that up
(directories, permissions, etc), so it's unclear to me why they would
care to have the ability to modify these things through ALTER SYSTEM.

Also, to reiterate, what this patch is primairly adding, from my pov
anyway, is a way for DBAs to modify settings where they don't have
access to do so directly.  Today, you can prevent that from happening
while giving the DBA "superuser" (which is required generally because
we don't have sufficiently fine-grained control to avoid it) by making
postgresql.conf root-owned.  To be clear, I'm not suggesting that this
is some malicious act on the part of the DBA.

In the end, I'd prefer that we shrink up the config file to just those
items which really need to be in a config file, have a conf.d structure
which allows tools like puppet/chef to more easily break up and have
different components (eg: logging) configured specially for certain
classes of systems, and then move all of the internal-to-PG type of
config (enable_*, etc) into a catalog which is modified through an
'ALTER CLUSTER SET' type command, allowing DBAs to set parameters
across the entire cluster instead of just for a given database or role.

Josh, I really have to ask- are these people who are implementing puppet
to control these configs really clamoring to have an 'ALTER SYSTEM' PG
command to have to code against instead of dealing with text files?  I
feel like you're arguing for these parameters to be modifiable through
ALTER SYSTEM on the grounds that these parameters need to be set at some
point and in some way and not because having them set through ALTER
SYSTEM actually makes any *sense*.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: David Johnston
Date:
Subject: Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])