Re: more backtraces

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Dec 13, 2019 at 7:26 AM Peter Eisentraut
>> Are people interested in backtraces on abort()? That was asked for in
>> an earlier thread.

FWIW, I don't have too much of an opinion about abort() yet.
Aren't we covering most of the possible cases for that already?
I don't think that direct abort() calls are considered good style
in the backend; it'd mostly get reached via Assert or PANIC.

> It would make life a lot easier for me if I never had to explain to a
> customer (1) how to install gdb or (2) that they needed to get $BOSS
> to approve installation of development tools on production systems.

Sure, but this facility is not going to have that end result, because
the output just isn't detailed enough. If it were, I'd be more interested
in taking risks to get the output. But as it stands, we're going to
need more information in a large fraction of cases, so I'm dubious
about doing anything that might actually interfere with collecting
such information.

> Being able to get debugging information from
> failures that happen on those installations that enables us to fix
> things without having to go through a time-consuming process of
> guesswork and attempted reproduction is really valuable. A stack trace
> can turn a lengthy nightmare into a quick fix.

I think you are supposing that these traces will be as useful as gdb
traces. They won't. In particular, where a gdb trace will almost
always localize the problem to a line of C code, with these you're
quite lucky if you can even localize to a specific function. That
issue is mitigated for the existing use-cases by the fact that there's
also a reported error message or assertion condition, so you can use
that to narrow down the trap site. But that won't help for SIGSEGV.

I think that the most useful next steps would involve trying to get
better printouts from the cases this code already traps, rather than
extending it to more cases. Maybe eventually we'll feel that this
code is useful and reliable enough to justify trying to insert it
into SIGSEGV cases; but we're not there today.

regards, tom lane