Re: custom variables and PGC_SUSET issue

Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

Yeah; in this particular case, the value is just plain invalid for
everybody. I think it just happens that postmaster didn't see it
because it was valid when it was started (i.e. the file got edited and a
SIGHUP sent, introducing the invalid value but not adopted anywhere).

> 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.

I was thinking that the solution would be to promote DEBUG3 to LOG in
the case of a custom variable. This would be noisy as you say, but I
don't see any other option; at least it would just be the custom
variables. This didn't work for reasons that we haven't been
investigated yet (we discovered this late last week and I've been busy
with 9.1 translations).

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support