On Fri, Dec 19, 2014 at 9:36 PM, Andres Freund <and...@2ndquadrant.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.
> 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. 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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
