Re: Little confusing things about client_min_messages. - Mailing list pgsql-hackers

From Tomonari Katsumata
Subject Re: Little confusing things about client_min_messages.
Date
Msg-id 531D52D5.5050300@po.ntts.co.jp
Whole thread Raw
In response to Re: Little confusing things about client_min_messages.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Little confusing things about client_min_messages.  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [bug fix] pg_ctl always uses the same event source
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.