Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

On 10/31/12 12:17 PM, Magnus Hagander wrote:

The idea at the time was to use the include *directory* functionality,
for say a "config.d" directory in pgdata. The builtin one would then
use a predictable filename in this directory, so that the DBA who
prefers it can drop files both before and after that file into the
directory.

That's how I remember things as well.  Unfortunately Amit's proposal seems like an even more complicated version of ideas that were clearly beaten down multiple times over many years now, partly for being too complicated.

The only idea I remember ever crossing the gap between the "edit by hand" and "tool config" crowd was based on the include directory concept.  The bugs in that implementation are finally worked out and the include_dir feature committed recently, so now it's possible to consider using it as a building block now.

Here is a much simpler proposal for example:

-Add a configuration subdirectory to the default installation.  Needs to follow the config file location, so things like the Debian relocation of postgresql.conf still work.  Maybe it has zero files; maybe it has one that's named for this purpose, which defaults to the usual:

# Don't edit this file by hand!  It's overwritten by...

-Have the standard postgresql.conf end by including that directory
-SQL parameter changes collect up all other active parameter changes, rewrite that file, and signal the server.  If any change requested requires a full server restart. warn the user of that fact.

And that's basically it.  Cranky old-timers can remove the include directive and/or directory if they don't like it, act as if nothing has changed, and move along.  Everyone else gets the beginning of a multiple co-existing tool change standard.

The only obvious bad case I can think of here is if someone has left the directory there, but deleted the include_dir statement; then the file would be written successfully but never included.  Seems like in the worst case the postgresql.conf parser would just need to flag whether it found the default directory included or not, to try and flag avoid obvious foot shooting.

Some of the better received ideas I floated for merging the recovery.conf file seemed headed this way too.  That also all blocked behind the include directory bit being surprisingly tricky to get committed.  So that's possible to revive usefully now.  And as much as I hate to expand scope by saying it, both changes should probably be tackled at once.  It's important to make sure they're both solved well by whatever is adopted, they are going to co-exist as committed one day.