Alvaro Herrera <alvherre@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
