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

On Fri, Nov 2, 2012 at 2:19 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> 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:
>

What do you mean by "needs to follow"? In particular, do you mean that it
should be relative to postgresql.conf? I think that would actually be a
*problem* for any system that moves the config file away, like debian,
since you'd then have to grant postgres write permissions on a directory in
/etc/...

> # 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.
>

Yes. And we could pretty easily find that - have the function that reloads
the config file actually check the source file and line number to make sure
it matches the one fro mthe auto file, and give a WARNING if it doesn't
(which indicates that either the file isn't included, or something else
"later in the chain" overwrote it)

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.
>

Yeah, we don't need the code for both, but we certainly need a "reasonable
design" capable of dealing with both, so we don't paint ourselves into a
corner.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/