Alvaro Herrera <alvhe...@commandprompt.com> writes: > Another thing we detected some days ago is that a custom variable in a > module not loaded by postmaster, does not seem to get reported > appropriately when an invalid value is set on postgresql.conf and > reloaded: backends report problems with DEBUG3, only postmaster uses > LOG, but since postmaster isn't loading the module, nothing happens.
This is just an instance of the general problem that the current design assumes all processes will have the same opinion about the validity of settings read from postgresql.conf. We discussed that back in July: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00850.php but it wasn't clear to me that any consensus had been reached about how to change the behavior. I proposed that we should let processes adopt individual settings even if they thought other ones were invalid; that gets rid of some of the issues, but it doesn't really address how we should report problems when only some of the processes think there's a problem. I don't think we can just s/DEBUG3/LOG/, because of the log clutter that will result when they all think there's a problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
