Re: quieting DEBUG3

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: quieting DEBUG3
Дата
Msg-id CAMsr+YHvpHWXeZcqoLHGoZJhMmDkh_JsU+g2EqeSRvf=yOS4dg@mail.gmail.com
обсуждение исходный текст
Ответ на quieting DEBUG3  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: quieting DEBUG3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 28 October 2015 at 04:52, Robert Haas <robertmhaas@gmail.com> wrote:

> Thoughts?

I agree with you that DEBUG3 is currently impractical. So much so that
when testing/debugging I often change log severities of messages of
interest so they'll show up at DEBUG2 instead, rather than running in
DEBUG3.

Simplifying the StartTransaction log to a single message line is
clearly sensible.

I tend to see a lot of:

DEBUG:  StartTransactionCommand
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG:  ProcessUtility
DEBUG:  CommitTransactionCommand
DEBUG:  StartTransactionCommand
DEBUG:  ProcessQuery
DEBUG:  CommitTransactionCommand
DEBUG:  StartTransactionCommand
DEBUG:  ProcessQuery
DEBUG:  CommitTransactionCommand
DEBUG:  StartTransactionCommand
DEBUG:  ProcessUtility
DEBUG:  CommitTransactionCommand
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:           END; state: INPROGR,
xid/subid/cid: 3778/1/2, nestlvl: 1, children:

It's pretty spammy, and the StartTransactionCommand /
CommitTransactionCommand entries don't seem to add any useful
information.

I'm not so sure about bumping transaction tracing down to DEBUG5,
given that transaction control is pretty important, and can be an
issue when chasing problems with cache accesses, etc. There's a lot of
other output, too, and once simplified to one line I think it's
reasonable to retain at DEBUG3.

I'd be pretty happy to get:


DEBUG:  StartTransaction(1): blockState: DEFAULT; state: INPROGR,
xid/subid/cid: 0/1/0
DEBUG:  ProcessUtility
DEBUG:  ProcessQuery
DEBUG:  ProcessQuery
DEBUG:  ProcessUtility
DEBUG:  CommitTransaction(1): blockState: END; state: INPROGR,
xid/subid/cid: 3778/1/2

instead.

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". But that
shouldn't hold up the simplifications you propose here, except maybe
the DEBUG3 to DEBUG5 change.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again