Re: quieting DEBUG3

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quieting DEBUG3
Date: 2016-11-16 16:53:21
Message-ID: CA+TgmobNcH=vGM-VRmdwr+19+yNyGMy+r5RuQ2HGmn8DH9+jrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 28, 2015 at 3:10 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>
>> Another point I want to reiterate - because nobody seems to be
>> addressing it - is that some of these messages are totally useless. I
>> grant that printing the transaction state (XIDs, CIDs, etc.) is
>> useful. But does anybody really think that it's useful for every
>> statement to *additionally* generate DEBUG: CommitTransactionCommand?
>> Who looks at that? What value does it have? We do not print a
>> message when any other function that is called for every query is
>> entered - why that one?
>
> No, it is useless, let's get rid of it. Maybe it was a useful debugging
> tool when postgres.c was being developed, but it's not useful now and
> instead very bothersome.
>
>> Whether we adjust the log levels of the messages we have or not, we
>> surely ought to get rid of the ones that are useless clutter.
>
> Agreed. I liked your proposal for reduction of transaction state
> printout to a single, denser line.
>
>> Can anyone think of a single instance in which that particular message
>> has been useful in debugging ... anything?
>
> Not I.

Right: me either. So, here is a series of three patches.

0001 completely removes the debug messages for
StartTransactionCommand, CommitTransactionCommand, ProcessQuery, and
ProcessUtility. AFAICS, those are entirely log spam. Nobody ever
wants to see them; they are a pure waste of cycles.

0002 adjusts the ShowTransactionState() output. Every call to
ShowTransactionState() currently produces N + 1 lines of log output,
where N is the number of entries on the transaction state stack. With
this patch, each call to ShowTransactionState() produces N lines of
output. All of the same information is still printed. In the common
case where N = 1, this reduces the number of lines of output by 50%
without losing any information. The individual lines are also a bit
shorter, again without removing any information, but just tightening
up the format.

0003 reduces the ShowTransactionState() output from DEBUG3 to DEBUG5.
I did find this output help in some of the parallel query development,
but I think the need to look at these messages is going to be
uncommon. Developers might care, but not often, and users never will.
Even after 0002 the log volume from turning this on is very high, so I
think it makes sense to push this down to a lower level.

If anybody objects to these, please say which specific patch you
object to and for what reason. Last year's discussion veered off into
a discussion of what the general policy for setting DEBUGn levels
ought to be, which didn't reach any conclusion, but I don't think that
should bar clear improvements. I think that all of these are
improvements, and that 0001 and 0002 are particularly clear-cut.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
0001-Remove-uninformative-DEBUG-messages.patch binary/octet-stream 1.7 KB
0002-Tighten-up-debugging-messages-that-print-the-transac.patch binary/octet-stream 2.9 KB
0003-Reduce-transaction-status-debugging-messages-to-DEBU.patch binary/octet-stream 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-16 16:58:02 Re: proposal: psql \setfileref
Previous Message Karl O. Pinc 2016-11-16 16:38:57 Re: Patch to implement pg_current_logfile() function