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