From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Suppressing elog.c context messages (was Re: Wait free LW_SHARED acquisition) |
Date: | 2014-12-23 17:41:29 |
Message-ID: | 20141223174129.GA23613@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-12-22 10:35:35 +0530, Amit Kapila wrote:
> On Fri, Dec 19, 2014 at 9:36 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
> wrote:
> >
> > Hi,
> >
> > When debugging lwlock issues I found PRINT_LWDEBUG/LOG_LWDEBUG rather
> > painful to use because of the amount of elog contexts/statements
> > emitted. Given the number of lwlock acquirations that's just not doable.
> >
> > To solve that during development I've solved that by basically
> > replacing:
> > if (Trace_lwlocks)
> > elog(LOG, "%s(%s %d): %s", where, name, index, msg);
> >
> > with something like
> >
> > if (Trace_lwlocks)
> > {
> > ErrorContextCallback *old_error_context_stack;
> > ...
> > old_error_context_stack = error_context_stack;
> > error_context_stack = NULL;
> > ereport(LOG,
> > (errhidestmt(true),
> > errmsg("%s(%s %d): %s", where, T_NAME(lock),
> > T_ID(lock), msg)));
> >
> > I think it'd generally be useful to have something like errhidecontext()
> > akin to errhidestatement() to avoid things like the above.
> >
>
> Under this proposal, do you want to suppress the context/statement
> unconditionally or via some hook/variable, because it might be useful to
> print the contexts/statements in certain cases where there is complex
> application and we don't know which part of application code causes
> problem.
I'm proposing to do model it after errhidestatement(). I.e. add
errhidecontext().
I've attached what I was tinkering with when I wrote this message.
> > The usecases wher eI see this as being useful is high volume debug
> > logging, not normal messages...
> >
>
> I think usecase is valid, it is really difficult to dig such a log
> especially when statement size is big.
Right, that was what triggered to look me into it. I'd cases where the
same context was printed thousands of times.
> Also I think even with above, the number
> of logs generated are high for any statement which could still make
> debugging difficult, do you think it would be helpful if PRINT_LWDEBUG
> and LOG_LWDEBUG are used with separate defines (LOCK_DEBUG and
> LOCK_BLOCK_DEBUG) as in certain cases we might want to print info
> about locks which are acquired after waiting or in other words that gets
> blocked.
Hm, that seems like a separate thing. Personally I don't find it
interesting enough to write a patch for it, although I could see it
being interesting for somebody.
If you're looking at that level it's easy enough to just add a early
return in either routine...
Greetings,
Andres Freund
Attachment | Content-Type | Size |
---|---|---|
0001-Add-capability-to-suppress-CONTEXT-messages-to-elog-.patch | text/x-patch | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | José Luis Tallón | 2014-12-23 17:45:26 | Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes |
Previous Message | José Luis Tallón | 2014-12-23 17:34:08 | Re: Proposal: two new role attributes and/or capabilities? |