Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> > I really just don't buy that- I've already put forward suggestions for
> > how to deal with it, but no one here seems to understand the
> > distinction. Modifying listen_addresses through ALTER SYSTEM is akin to
> > ISC/bind allowing changes to its listen_addresses equivilant through
> > dynamic DNS updates. Would it be possible to implement? Sure. Does it
> > make any sense? Certainly not.
>
> I very much want to change stuff like wal_level, listen_addresses and
> shared_buffers via ALTER SYSTEM. Configuration variables like that
> (PGC_POSTMASTER stuff mostly) are the prime reason why you actually need
> to change postgresql.conf instead of changing per user/database
> settings.

wal_level and shared_buffers I can buy, but listen_addresses? The most
typical change there is going from localhost -> '*', but you've got to
be on the box to do that. Anything else and you're going to need to be
adding interfaces to the box anyway and hacking around in
/etc/network/interfaces or what-have-you.

> > Because we've got crap mixed into postgresql.conf which are bootstrap
> > configs needed to get the system started. Those things, in my view
> > anyway, fall much more into the category of "resources which should be
> > managed outside the database" than pg_hba.conf.
>
> I think the problem with your position in this thread is that you want
> to overhaul the way our configuration works in a pretty radical
> way. Which is fair enough, there certainly are deficiencies. But it's
> not the topic of this thread.

You and Robert both seem to be of the opinion that this hack which
brings postgresql.conf into the database via ALTER SYSTEM is a-ok
because it's moving us "forward" in someone's mind, but it really is
developing a system configuration management system which *looks* like a
first-class citizen when it actually falls woefully short of that.

There is absolutely no question in my mind that this will be a huge
support pain, from the first "ALTER SYSTEM SET shared_buffers = blah;
SHOW shared_buffers;" to the "why can't my database start?!? it's
complaining it can't allocate memory but I keep changing postgresql.conf
and nothing works!" I'm simply not convinced that this is moving us
forward nor that we will end up with more benefit than pain from it.

Thanks,

Stephen