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

Greg,

* Greg Stark (stark(at)mit(dot)edu) wrote:
> Writing out each guc in a separate file is a singularly bad idea. It's
> going out of our way to confuse users about what's going on and how
> they're expected to interact with the settings files and it actively
> makes it harder or nearly impossible to protect against simple
> failures.

I agree that having a separate file for each GUC is a bad idea. That
said, I still contend that there's a difference between files in $PGDATA
and files found in /etc.

> 1) The whole reason for conf.d directories for things like Apache or
> cron or whatever is so that other software can drop in snippets
> without having to parse and edit a file in place. We *do not* want
> users doing that inside PGDATA.

Agreed. That said, if users *want* a separate file per GUC in their
/etc, we can let them do that with the conf.d structure.

> I'm not even clear we do want this in /etc since none of our GUC
> options are repeatable things like Apache virtual servers. It actually
> makes *more* sense for pg_hba than it does for gucs. I think we can
> assume that in the future we'll have something like it however.

I tend to agree with this also, though I can imagine wanting to separate
things in a conf.d directory ala exim's conf.d directories, to allow
tools like puppet to manage certain things environment-wide (perhaps
krb_server_keyfile) while other configuration options are managed
locally.

> If we just keep a backup copy of the settings file for each change
> then it would be easy for people to diff from one version to another
> and see all the changes together and easy for them to restore an old
> copy if the current one isn't starting up. If they're in a million
> tiny files then users would have to keep a backup copy of the whole
> directory and dig thorugh a recursive diff of the whole directory. Or
> they would have tons of backup files for different settings at
> different times and need to figure out which ones were in effect at a
> given time.

This I don't entirely follow though. Above, you don't want users
monkeying around in PGDATA dropping files, but it's ok for them to be
diffing them and, presumably, rewritting them with older version when
they feel the need to?

I agree that we should provide a way for users to get old versions of
their config and know when things changed, but, to be honest, I'd like
to see that kind of audit log information for various catalog tables
too- eg: pg_database. If we had event triggers and they could be fired
for ALTER SYSTEM along with ALTER DATABASE, then we could have an audit
system with an audit table which takes who did what when, old value, new
value, etc..

Thanks,

Stephen