On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 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).
That was precisely my logic. Tools can check the "source" of the
current value and provide an error if it overrides their new settings
whereas the reverse doesn't work. I also think that in general manual
human intervention should trump anything done behind the user's back.
The systems that break this rule invariably end up driving me nuts.
I think the concern about settings interfering is valid for things
like general-purpose tuning tools. But we will have modules which will
need some individual configuration too. And you could imagine having
things like a SSLConfigurator which might not have much chance of
conflicting with anything else. And in any case, like you pointed out,
if you do run two general-purpose auto-tuners the second one could
give a warning that it's overriding the first one or that its settings
will be overridden based on the priority of the files.
--
greg