On 2015-01-26 18:30:13 -0600, Jim Nasby wrote:
> On 12/23/14 11:41 AM, Andres Freund wrote:
> >>>> >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.
>
> In case anyone picks this up... this problem exists in other places too, such as RAISE DEBUG in plpgsql. I think it'd
beuseful to have clien_min_context and log_min_context that operate akin to *_min_messages but control context output.
I've pushed it already IIRC. I don't think we can just apply it without
regard for possible users to that many cases - I think the RAISE DEBUG
case is better addressed by a plpgsql option to *optionall* suppress
context, than do it unconditionally. That's discussed somewhere nearby.
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services