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, committed.
--
Robert Haas
Ente
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 & Servic
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, CIDs, etc.) is
>> useful. B
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
> state
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 once or a few times per
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 intended for, so there's some guidance on what level
>>> to emit messages
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 playing "pick a number".
>
> +1 ... I doubt
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 playing "pick a number".
>
> +1 ... I doubt
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 a holistic way.
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
DEBUG3.
Simplifying the St
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: unnam
11 matches
Mail list logo
