Re: custom variables and PGC_SUSET issue

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

In response to

Browse pgsql-hackers by date

  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