Re: backtrace_on_internal_error - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: backtrace_on_internal_error
Date
Msg-id CAEze2WhTMeQM8TkYVEsGO2nXvaikN_GxGn1Ezs=Yi33WEMm2Wg@mail.gmail.com
Whole thread Raw
In response to Re: backtrace_on_internal_error  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: backtrace_on_internal_error
Re: backtrace_on_internal_error
Re: backtrace_on_internal_error
List pgsql-hackers
On Tue, 5 Dec 2023 at 19:30, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Dec 5, 2023 at 1:28 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> > 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.
>
> Why?

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)



pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Remove WIN32 conditional compilation from win32common.c
Next
From: Joe Conway
Date:
Subject: Re: Emitting JSON to file using COPY TO