Re: Little confusing things about client_min_messages.

Поиск
Список
Период
Сортировка
От Tomonari Katsumata
Тема Re: Little confusing things about client_min_messages.
Дата
Msg-id 531D52D5.5050300@po.ntts.co.jp
обсуждение исходный текст
Ответ на Re: Little confusing things about client_min_messages.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Little confusing things about client_min_messages.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi Tom, Bruce,

Thank you for your response.

(2014/03/09 2:12), Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> On Sat, Mar 8, 2014 at 11:31:22AM -0500, Tom Lane wrote:
>>> Tomonari Katsumata <t.katsumata1122@gmail.com> writes:
>>>> [ client_min_messages = info is not documented ]
>
>>> That's intentional, because it's not a useful setting. Even more so
>>> for the other two.
>
>> Well, 'info' is between other settings we do document, so I am not clear
>> why info should be excluded. It is because we always output INFO to the
>> client? From elog.c:
>
>> if (ClientAuthInProgress)
>> output_to_client = (elevel >= ERROR);
>> else
>> output_to_client = (elevel >= client_min_messages ||
>> elevel == INFO);
>
> Right, so if you did set it to that, it wouldn't be functionally different
> from NOTICE.
>
I understand it's intensional.
We can set INFO but it doesn't have any difference from NOTICE
because all INFO messages are sent to client.
So it is hidden from the document.

The word "valid" in the document has meant "meaningful".
I've misread it was "setable".


> So no, I don't think we ought to be advertising these as suggested
> values. A saner proposed patch would be to remove them from the
> valid values altogether. We probably had some good reason for leaving
> them in the list back when, but I'm having a hard time reconstructing
> what that would be.
>
Adding FATAL and PANIC to client_min_messages is done at below-commit.
8ac386226d76b29a9f54c26b157e04e9b8368606
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8ac386226d76b29a9f54c26b157e04e9b8368606

According to the commit log, it seems that the purpose
is suppressing to be sent error message to client when "DROP TABLE".
In those days(pre 8.1), we did not have "DROP IF EXISTS" syntax,
so it was useful.

If this was the reason, now(from 8.2) we have "DROP IF EXISTS" syntax,
so we could delete FATAL and PANIC from client_min_messages valid value.
Attached patch do it. Please check it.

regards,
-----------
Tomonari Katsumata


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [bug fix] pg_ctl always uses the same event source
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: UNION ALL on partitioned tables won't use indices.