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

From Andres Freund
Subject Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 20130830133926.GG5019@alap2.anarazel.de
Whole thread Raw
In response to Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Stephen Frost <sfrost@snowman.net>)
Responses Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
List pgsql-hackers
On 2013-08-30 09:26:32 -0400, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
> > > It's not the OPs guy that I'm worried about using ALTER SYSTEM- I don't
> > > expect them to have any clue about it or care about it, except where it
> > > can be used to modify things under /etc which they, rightfully, consider
> > > their domain.
> > 
> > I think for the scenarios you describe it makes far, far much more sense
> > to add the ability to easily monitor for two things:
> > * on-disk configuration isn't the same as the currently loaded (not
> >   trivially possible yet)
> 
> That would certainly help.  I don't know that it needs to be technically
> 'trivial', but at least having check_postgres.pl or something which can
> alert on it would be an improvement.  Clearly, that would be valuable
> today (assuming it doesn't already exist somewhere..  it might).

Technically trivial in the sense that it should be queryable from SQL
without having to write code in an untrusted PL ;).

I guess storing the file modification date along the file/location a GUC
is originating from would be good enough. Then you could write a query
using pg_stat_file() to make sure they are up2date.

> > * Configuration variables only come from locations that are approved for
> >   in your scenario (Already possible, we might want to make it even easier)
> 
> That an interesting notion; do you have something specific in mind..?
> The easiest, imv anyway, would be that options set in postgresql.conf
> can't be overridden, but that gets us into the bootstrap problem that
> people seem to be concerned about.  It would also be a change to how
> postgresql.conf is parsed today which some people would be annoyed by.
> Having some configuration option which says what can be modified by
> alter system doesn't strike me as a terribly good solution either.

I think changing the precedence of options in postgresql.conf has about
zero chance.

Currently you can do something like:
SELECT name FROM pg_settings WHERE sourcefile IS NOT NULL AND sourcefile <>
'/etc/postgresql/9.2/main/postgresql.conf';

To be easily usable we should have two new columns in pg_settings:
* reset_sourcefile
* reset_sourceline
And an easy way to get the absolute path of
* postgresql.conf
* auto.conf or whatever we name it.

That would make it possible to easily write a query that works across
intallation that warns about any values stored in auto.conf, even if
they are overwritten by a per-user config or similar.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: David Johnston
Date:
Subject: Re: Variadic aggregates vs. project policy
Next
From: Robert Haas
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])