From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Date: | 2012-11-02 11:17:40 |
Message-ID: | CABUevExyCy=uTSisKwSQPJt1n9N7pN4RCJ8cT6y4SOLxCih=qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2012-11-02 11:52:07 | Bug in ALTER COLUMN SET DATA TYPE ? |
Previous Message | Alexander Korotkov | 2012-11-02 08:54:33 | Re: gistchoose vs. bloat |