Re: Permanent settings - Mailing list pgsql-hackers

Le mardi 19 février 2008, Gregory Stark a écrit :
> "Magnus Hagander" <magnus@hagander.net> writes:
> > Yeah, that may actually be a very good way to implement it. I don't like
> > the idea of continously appending to an existing file, but if we did have
> > a separate file with a tightly controlled format that would be doable.
>
> +1
>
> Separating the automatically written configuration and the explicit user
> configuration is definitely the right approach. My experience comes from
> Debian where packages editing their own configuration files is verboten.
> Otherwise you run into problems reconciling user-made changes and automatic
> changes.
>
> The include file method is workable but isn't perfect. What happens if a
> user connects with pgadmin and changes a parameter but that parameter is
> overridden by a variable in the config file?
>
> The alternative is to have two files and read them both. Then if you change
> a variable which is overridden by the other source you can warn that the
> change is ineffective.

Ok, here's another idea, which only merits could well be to be different :)

What about having a postgresql.conf.d directory containing a file per setting,
maybe with a subdir per section. If I take Josh Berkus example, we'd have
either: $PGDATA/postgresql.conf.d/allow_system_table_mods $PGDATA/postgresql.conf.d/archive_command
$PGDATA/postgresql.conf.d/archive_mode $PGDATA/postgresql.conf.d/archive_timeout 

or: $PGDATA/postgresql.conf.d/developer_options/allow_system_table_mods
$PGDATA/postgresql.conf.d/wal/settings/archive_command$PGDATA/postgresql.conf.d/wal/settings/archive_mode
$PGDATA/postgresql.conf.d/wal/settings/archive_timeout$PGDATA/postgresql.conf.d/wal/fsync/fsync
$PGDATA/postgresql.conf.d/wal/fsync/wal_buffers

Each file would then only contains the parameter value, with or without
comments in it, e.g.: cat $PGDATA/postgresql.conf.d/log/where/log_destination 'syslog' # # This is a long comment about
whywe moved to syslog because of # blah blah blah blah lah # 

This would solve a part of the configuration file parsing issues and I think
would ease much of the 'make it all automatic and writable by backends, and
still editable by user without too much confusion in the file(s)', but does
nothing about Magnus remarks about comments (mis-)organisation in the file.
Or we could force the files format to have the value in the first line, no
comments and values on the same line allowed, then anything on following
lines.

Of course you end up with a forest of files, and that would be a pain to
manually edit, but provided the categorization in pg_settings, it seems easy
enough to automatically transform postgresql.conf to the 'forest', so there
could be some way for the DBA to say he wont ever want resort to automatic
configuration handling. Then postgresql.conf is the edited file and reload
will have PostgreSQL generate the forest before to use it.

Hope this helps,
--
dim