From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, ash <ash(at)commandprompt(dot)com> |
Subject: | Re: custom variables and PGC_SUSET issue |
Date: | 2011-09-07 19:26:20 |
Message-ID: | 29178.1315423580@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-09-07 19:42:45 | Re: [PATCH] Log crashed backend's query (activity string) |
Previous Message | Andrew Dunstan | 2011-09-07 19:23:25 | Re: custom variables and PGC_SUSET issue |