On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers