Subject: Re: backtrace_on_internal_error

From: Nathan Bossart <[email-masked]>
Date: Tue, 5 Dec 2023 12:28:45 -0600

On Tue, Dec 05, 2023 at 01:16:22PM -0500, Robert Haas wrote:
> I think we should consider unconditionally emitting a backtrace when
> an elog() is hit, instead of requiring a GUC. Or at least any elog()
> that's not at a DEBUGn level. If the extra output annoys anybody, that
> means they're regularly hitting an elog(), and it ought to be promoted
> to ereport().

Perhaps this should be a GUC that defaults to LOG or ERROR.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

---

From: Robert Haas <[email-masked]>
Date: Tue, 5 Dec 2023 13:30:23 -0500

> Perhaps this should be a GUC that defaults to LOG or ERROR.

Why?

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

---

From: Matthias van de Meent <[email-masked]>
Date: Tue, 5 Dec 2023 19:47:25 +0100

> > Perhaps this should be a GUC that defaults to LOG or ERROR.

I can't speak for Nathan, but my reason would be that I'm not in the
habit to attach a debugger to my program to keep track of state
progression, but instead use elog() during patch development. I'm not
super stoked for getting my developmental elog(LOG)-s spammed with
stack traces, so I'd want to set this at least to ERROR, while in
production LOG could be fine.

Similarly, there are probably extensions that do not use ereport()
directly, but instead use elog(), because of reasons like 'not
planning on doing translations' and 'elog() is the easier API'.
Forcing a change over to ereport because of stack trace spam in logs
caused by elog would be quite annoying.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)

---

From: Robert Haas <[email-masked]>
Date: Tue, 5 Dec 2023 14:59:46 -0500

> caused by elog would be quite annoying.

That does seem like a fair complaint. But I also think it would be
really good if we had something that could be enabled unconditionally
instead of via a GUC... because if it's gated by aa GUC then it often
won't be there when you need it.

---

From: Nathan Bossart <[email-masked]>
Date: Tue, 5 Dec 2023 14:06:10 -0600

>> > Perhaps this should be a GUC that defaults to LOG or ERROR.

Sorry, I should've explained why in my message.

> caused by elog would be quite annoying.

My main concern was forcing extra logging that users won't have a great way
to turn off (except for maybe raising log_min_messages or something).
Also, it'd give us a way to slowly ramp up backtraces over a few years
without suddenly spamming everyones logs in v17.  For example, maybe this
GUC defaults to PANIC or FATAL in v17.  Once we've had a chance to address
any common backtraces there, we could bump it to ERROR or WARNING in v18.
And so on.  If we just flood everyone's logs immediately, I worry that
folks will just turn it off, and we won't get the reports we are hoping
for.

I know we already have so many GUCs and would like to avoid adding new ones
when possible.  Maybe this is one that could eventually be retired as we
gain confidence that it won't obliterate the log files.