* Andres Freund (andres@2ndquadrant.com) wrote:
> Technically trivial in the sense that it should be queryable from SQL
> without having to write code in an untrusted PL ;).
hah.
> 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.
Wouldn't you want to actually look at the GUC and see if the value is
different also? Just knowing that postgresql.conf changed doesn't mean
you want every value to say it's different... It's entirely possible
that the file was rewritten or touch'd but the configuration is
identical.
> > > * 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.
Sadly, you're probably right.
> 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.
I had the impression that 'approved for' above meant something which
actually *enforced* it rather than just another monitoring check..
Thanks,
Stephen