It sounds like there's a consensus brewing here on what should get done
with this particular patch now. Let me try to summarize:
-The new feature should be activated by allowing you to specify a
directory to include in the postgresql.conf like this:
includedir 'conf'
With the same basic semantics for how that directory name is interpreted
as the existing "include" directive. Tom has some concerns on how this
will be implemented, with "glob" portability to Windows and error cleanup
as two of the issues to consider.
-Within that directory, only file names of the form "*.conf" will be
processed. More flexibility is hard to implement and of questionable
value.
-The order they are processed in will be alphabetical. This allows (but
doesn't explictly require) using the common convention of names like
"99name" to get a really obvious ordering.
-The default postgresql.conf should be updated to end with the sample
includedir statement shown above. This will make anything that goes into
there be processed after the main file, and therefore override anything in
it.
-An intended purpose here is making tools easier to construct. It's
impractical to expect every tool that touches files in the config
directory to do an exhaustive sweep to find every other place there might
be a conflict and comment them all out. The fact that pg_settings shows
users the exact file and line they setting that is the active one is a
good enough tool to allow DBAs to work through most of the problem cases.
And as far as how it impacts planning:
-A future patch to initdb could move the changes it makes from the primary
file to one in the config directory. It might make sense to use a name
like 00initdb.conf to encourage a known good naming practice for files in
the config directory; that doesn't need to get nailed down now though.
-This patch makes it easier to envision implementing a smaller default
postgresql.conf, but it doesn't require such a change to be useful.
-SET PERSISTENT is still a bit away. This patch assists in providing a
cleaner preferred way to implement that, and certainly doesn't make it
harder to build. The issue of how to handle backing out changes that
result in a non-functional server configuration is still there. And
there's some support for the idea that the SQL interface should do more
sanity checks to make sure its setting changes aren't being overridden by
config files parsed later than we might expect from external tuning tools.
Magnus, was there anything else you wanted feedback on here?
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
