Re: custom variables and PGC_SUSET issue

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, ash <ash@commandprompt.com>
Date: 2011-09-07T19:26:20Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of mi sep 07 14:49:45 -0300 2011:
>> 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.

That's not much of a fix because (a) the behavior is still pretty
undesirable, and (b) it supposes that this sort of failure can only
occur for custom variables.  The previous discussion arose from a
different case entirely --- IIRC, it was from trying to specify
client_encoding in postgresql.conf, which the postmaster was happy with
but some backends were not because they had a database_encoding for
which there was no conversion.  There are probably a bunch of other
possibilities out there that we haven't hit yet, and if not today, there
certainly will be more in the future.  So I'm not very excited by a
proposed fix that makes assumptions about the exact reason why a process
rejects a particular GUC value.

			regards, tom lane