Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
