| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PATCH: backtraces for error messages |
| Date: | 2018-06-20 16:04:51 |
| Message-ID: | 20582.1529510691@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-06-20 11:20:49 -0400, Alvaro Herrera wrote:
>> I have no idea how expensive backtrace() and libunwind are, but I doubt
>> we want to pay the cost for every message before we know that error
>> requires the backtrace to be collected. Something like PGC_USERSET
>> server_min_backtraces=PANIC
>> might be a possible interface.
> Yes, most definitely. We can't do this everywhere. It's quite expensive
> to collect / build them. So I think we'd probably need another guc that
> controls when the information is collected, perhaps defaulting to PANIC.
The cost is a problem, and the dependencies on various additional
libraries are too. I wonder whether anything could be gained by
putting this stuff in an extension? Then we could have different
extensions for different backtrace libraries, and loading the extension
or not would be one avenue to control whether you were paying the cost.
(Though some control GUCs might be needed anyway.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-06-20 16:10:50 | Re: PATCH: backtraces for error messages |
| Previous Message | Andres Freund | 2018-06-20 16:04:34 | line numbers in error messages are off wrt debuggers |