From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Date: | 2012-11-03 01:38:49 |
Message-ID: | 509475A9.7080205@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -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.
+1
Simple, easy to understand, easy to customize.
> 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 can have the comment:
# this includes the default directory for extra configuration files
# do not delete or comment this out; remove any extra configuration
# files you don't want instead
... or similar to warn users. Frankly, if someone removes the
"includedir config/" line, we can presume they know what they are doing.
For that matter, some users might want to move the line to the beginning
of the file, instead of the end.
> 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.
Yes.
I'll also point out that includedir would help solve the issue of
"postgresql.conf is under Puppet, but I want to change the logging
options ..." more handily than current solutions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-11-03 01:44:25 | Re: RFC: Timing Events |
Previous Message | Daniel Farina | 2012-11-03 01:26:49 | Re: Synchronous commit not... synchronous? |