Re: Proposal for Allow postgresql.conf values to be changed via SQL

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com