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.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com