Re: custom variables and PGC_SUSET issue
От | Tom Lane |
---|---|
Тема | Re: custom variables and PGC_SUSET issue |
Дата | |
Msg-id | 29178.1315423580@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: custom variables and PGC_SUSET issue (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: