Re: backtrace_on_internal_error

On Fri, Dec 8, 2023 at 1:34 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Oh, very much agreed. But I suspect we won't quickly do the same for
> out-of-core extensions...

I feel like this is a problem that will sort itself out just fine. The
rules about using ereport() and elog() could probably be better
documented than they are, but doing that won't cause people to follow
the practices any more rigorously than they have been. However, a
change like this just might. If we make this policy change in core,
then extension authors will probably get pressure from users to clean
up any calls that are emitting excessively verbose log output, and
that seems like a good thing.

It's impossible to make an omelet without breaking some eggs, but the
thing we're talking about here is, IMHO, extremely important. Users
are forever hitting weird errors in production that aren't easy to
reproduce on test systems, and because most elog() calls are written
with the expectation that they won't be hit, they often contain
minimal information, which IME makes it really difficult to understand
what went wrong. A lot of these are things like - oh, this function
expected a valid value of some sort, say a relkind, and it got some
nonsense value, say a zero byte. But where did that nonsense value
originate? That elog message can't tell you that, but a stack trace
will.

The last change we made in this area that, at least for me, massively
improved debuggability was the change to log the current query string
when a backend crashes. That's such a huge help; I can't imagine going
back to the old way where you had basically no idea what made things
go boom. I think doing something like this can have a similarly
positive impact. It is going to take some work - from us and from
extension authors - to tidy things up so that it doesn't produce a
bunch of unwanted output, but the payoff will be the ability to
actually find and fix the bugs instead of just saying to a customer
"hey, sucks that you hit a bug, let us know if you find a reproducer."

--
Robert Haas
EDB: http://www.enterprisedb.com