On Fri, Nov 2, 2012 at 2:19 AM, Greg Smith <g...@2ndquadrant.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/
