public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: backtrace_on_internal_error
Date: Tue, 5 Dec 2023 14:06:10 -0600
Message-ID: <20231205200610.GA2761183@nathanxps13> (raw)
In-Reply-To: <CAEze2WhTMeQM8TkYVEsGO2nXvaikN_GxGn1Ezs=Yi33WEMm2Wg@mail.gmail.com>
References: <[email protected]>
<20231205174034.GA2757816@nathanxps13>
<CA+Tgmoas4qK-Um-RwSLAUXfKN+UothbofQ_3pfDtWGdrtaBNtA@mail.gmail.com>
<20231205182845.GD2757816@nathanxps13>
<CA+TgmoZROvY+URoUHwwO+wvdx-VdiGbqozh4+D0QuxWDE2uEHg@mail.gmail.com>
<CAEze2WhTMeQM8TkYVEsGO2nXvaikN_GxGn1Ezs=Yi33WEMm2Wg@mail.gmail.com>
On Tue, Dec 05, 2023 at 07:47:25PM +0100, Matthias van de Meent wrote:
> On Tue, 5 Dec 2023 at 19:30, Robert Haas <[email protected]> wrote:
>> On Tue, Dec 5, 2023 at 1:28 PM Nathan Bossart <[email protected]> wrote:
>> > Perhaps this should be a GUC that defaults to LOG or ERROR.
>>
>> Why?
Sorry, I should've explained why in my message.
> 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.
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.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: backtrace_on_internal_error
In-Reply-To: <20231205200610.GA2761183@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox