On 2018-06-20 12:04:51 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.)
I think the problem is that this most frequently is an issue when
investigating an issue for customers. Often enough it'll legally not be
possible to gain direct access to the system, and remotely instructing
people to install an extension and configure it isn't great. So if we
could, by default, include something better for PANICs etc, it'd be a
great boon - I think that's even clear from conversionations on the pg
lists (which often will be the more knowledgable people: How often did
we try hard to get a backtrace from a crash?
If we instead had a backtrace enabled for all PANICs and some FATALs by
default (and perhaps a SIGSEGV handler too), we'd be in a better
place. That'd obviously only work when compiled with support for
libraries, on platforms where we added support for that. But I think
that'd be quite the improvement already.
Greetings,
Andres Freund