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 be useful 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
