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.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
