Re: Parsing config files in a directory

Josh Berkus wrote:
> Kevin,
>
> > I'm talking about how the decision should be made as to which takes
> > precedence. It's fine to document which one *was* chosen, but that
> > doesn't eliminate the problem of conflicting settings making a mess.
> > Someone else (Robert maybe?) gave an explicit example of how three
> > files could have overlapping settings. Of course, *my* tool will name
> > its configuration file " !.conf".
>
> Hey, if a DBA wants to do that, then it's fine with me. They can check
> pg_settings afterwards to find out which was chosen.
>
> The precedence issues you (and Robert) are citing are no different from
> what we have currently in a single file. I absolutely can't tell you
> the number of hacked-up postgresql.conf files I've seen with the same
> setting appearing in more than 3 places. And with the conf file being
> over 1000 lines long, it's easy to miss that someone or some tool added
> another instance of the variable at the bottom.
>
> Plus we already support includes of single files. Why is an include of
> a directory controversial? If someone doesn't want to use it, they
> don't have to.

Sorry to be commenting late:

I am glad we are looking at how other projects do their configuration,
but I am concerned that we might be drawing conclusions from other
projects that don't apply to us.

For example, I assume the Apache directory configuration system works
well because the module file values typically don't conflict with the
values in other files.

The Unix /etc/rc.d system works, but does that have many cases where an
/etc/*.conf file sets a value that is overriden by a value in an
/etc/rc.d file?

I realize there are already problems in postgresql.conf where users put
a value multiple places, but at least there is a clear ordering
(top-to-bottom) so problems can be diagnosed. A top-level conf
file and a subdirectory of conf files seems to make things
extra-confusing.

I realize the goal of having a config file that can be easily modified
by tools and retaining the existing user-modified postgresql.conf file
too.

There was discussion of whether the directory files or postgresql.conf
file has precedence. If postgresql.conf has precedence, tools changing
values might not work, and if the directory has precendence, someone
changing postgresql.conf might have their changes ignored. The tools
can warn users if they think the change might be ignored (by checking
pg_settings), but someone modifying postgresql.conf can't get the same
warnings. I wonder if this is a good reason to give postgresql.conf
precedence (and have all postgresql.conf values commented-out by
default; no more initdb change in there).

A more radical approach would be for the server to refuse to start if a
setting is set in more than one file, and for the server to report both
locations. That would reduce the guesswork about problems.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +