Le mardi 19 février 2008, Gregory Stark a écrit : > "Magnus Hagander" <[EMAIL PROTECTED]> 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 why we 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
signature.asc
Description: This is a digitally signed message part.
