Re: quieting DEBUG3

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: quieting DEBUG3
Дата
Msg-id CA+Tgmobvoiz3vuyST5NXF5V-y06bkGLgKLvu57GGZWXTQYd-fw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: quieting DEBUG3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: quieting DEBUG3
Список 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 по дате отправления:

Предыдущее
От: Nathan Wagner
Дата:
Сообщение: Re: Add EXTRA_CFLAGS to configure
Следующее
От: Robert Haas
Дата:
Сообщение: Re: a raft of parallelism-related bug fixes