Re: quieting DEBUG3 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: quieting DEBUG3
Date
Msg-id CA+Tgmobvoiz3vuyST5NXF5V-y06bkGLgKLvu57GGZWXTQYd-fw@mail.gmail.com
Whole thread Raw
In response to Re: quieting DEBUG3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: quieting DEBUG3  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Wed, Oct 28, 2015 at 1:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> I think it'd be helpful to define some level of policy about what the
>> debug levels are intended for, so there's some guidance on what level
>> to emit messages on rather than playing "pick a number".
>
> +1 ... I doubt anyone has ever looked at that in a holistic way.

Well, I don't know that I could give really specific guidance on each
individual level, but what I think is pretty clear is that messages
which tell you about something that's likely to happen very frequently
should only appear if you have really cranked the logging up to the
maximum.   So a message that fires every time you touch a data block
had better be DEBUG5, but a message that fires at most once per
checkpoint cycle can afford to be DEBUG1.  Qualitatively, I think that
higher debug level (DEBUG1, DEBUG2) should focus on telling you about
things that are potentially interesting and maybe a little bit
unusual, while tracing messages that report things which are entirely
routine should use lower debug levels (DEBUG4, DEBUG5).

I agree with Craig that the transaction system is interesting and
important, but it's not the *only* interesting and important subsystem
we have ... and any log level below DEBUG2 is basically useless right
now; the stuff you want is almost guaranteed to be lost in the noise.

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



pgsql-hackers by date:

Previous
From: Nathan Wagner
Date:
Subject: Re: Add EXTRA_CFLAGS to configure
Next
From: Robert Haas
Date:
Subject: Re: a raft of parallelism-related bug fixes