Re: [HACKERS] quieting DEBUG3

2016-11-17 Thread Robert Haas
On Wed, Nov 16, 2016 at 12:00 PM, Alvaro Herrera wrote: > Robert Haas wrote: > >> Right: me either. So, here is a series of three patches. > > +1 to the general idea of the three patches. I didn't review nor test > them in detail. Thanks. Hearing no objections,

Re: [HACKERS] quieting DEBUG3

2016-11-16 Thread Alvaro Herrera
Robert Haas wrote: > Right: me either. So, here is a series of three patches. +1 to the general idea of the three patches. I didn't review nor test them in detail. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] quieting DEBUG3

2016-11-16 Thread Robert Haas
On Wed, Oct 28, 2015 at 3:10 PM, Alvaro Herrera 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,

Re: [HACKERS] quieting DEBUG3

2015-10-28 Thread Robert Haas
On Wed, Oct 28, 2015 at 1:51 AM, Tom Lane wrote: > Craig Ringer 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

Re: [HACKERS] quieting DEBUG3

2015-10-28 Thread Christopher Browne
On 27 October 2015 at 20:51, Tom Lane wrote: > > Craig Ringer 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

Re: [HACKERS] quieting DEBUG3

2015-10-28 Thread Jeff Janes
On Wed, Oct 28, 2015 at 6:57 AM, Robert Haas wrote: > On Wed, Oct 28, 2015 at 1:51 AM, Tom Lane wrote: >> Craig Ringer writes: >>> I think it'd be helpful to define some level of policy about what the >>> debug levels are

Re: [HACKERS] quieting DEBUG3

2015-10-28 Thread Robert Haas
On Wed, Oct 28, 2015 at 5:26 PM, Jeff Janes wrote: > 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

Re: [HACKERS] quieting DEBUG3

2015-10-28 Thread Alvaro Herrera
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 >

[HACKERS] quieting DEBUG3

2015-10-27 Thread Robert Haas
It's been my observation that setting client_min_messages or log_min_messages to DEBUG3 is almost invariably impractical, because every SQL statement spews about SIX messages about the transaction state: rhaas=# select 1; DEBUG: StartTransactionCommand DEBUG: StartTransaction DEBUG: name:

Re: [HACKERS] quieting DEBUG3

2015-10-27 Thread Craig Ringer
On 28 October 2015 at 04:52, Robert Haas 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

Re: [HACKERS] quieting DEBUG3

2015-10-27 Thread Tom Lane
Craig Ringer 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