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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
