Re: quieting DEBUG3 - Mailing list pgsql-hackers

On Wed, Oct 28, 2015 at 6:57 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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 figured it would go something like this:

DEBUG1 once or a few times per statement/autovac/checkpoint
DEBUG2 several times per statement/autovac/checkpoint (like once per
joined relation in the planner)
DEBUG3 once or a few times per row/block
DEBUG4 several times per row/block
DEBUG5 memory allocation.

>
> 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.

The main use I have for any of the DEBUG levels above 1 is to step
through them with vim in a specific source file to see what someone
felt was important to log when they were debugging that file in the
past.  Then I change the ones I like to LOG or NOTICE and recompile to
get a targeted verbose logging build.  This is not to disparage their
usefulness, it is hard to imagine me getting into a new part of the
code without the ability to use these archeological markers.  They are
often more useful than the /* comments */ .



Cheers,

Jeff