Re: backtrace_on_internal_error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>,
Peter Eisentraut <peter@eisentraut.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-05T20:08:22Z
Lists: pgsql-hackers
Matthias van de Meent <boekewurm+postgres@gmail.com> writes: > On Tue, 5 Dec 2023 at 19:30, Robert Haas <robertmhaas@gmail.com> wrote: >>> I think we should consider unconditionally emitting a backtrace when >>> an elog() is hit, instead of requiring a GUC. >> 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. Yeah, I would not be happy either with elog(LOG) suddenly getting 10x more verbose. I think it might be okay to unconditionally do this when elevel >= ERROR, though. (At the same time, I don't have a problem with the idea of a GUC controlling the minimum elevel to cause the report. Other people might have other use-cases than I do.) regards, tom lane
Commits
-
Add GUC backtrace_on_internal_error
- a740b213d4b4 17.0 landed
-
Fix variable name and comment
- 541e8f14a185 17.0 landed
-
Be more wary about OpenSSL not setting errno on error.
- ebbd499d4b55 16.2 landed
- 87b46ad90491 13.14 landed
- 551d4b28e445 15.6 landed
- 271d24f31ddd 12.18 landed
- 0a5c46a7a488 17.0 landed
- 07ce2432682d 14.11 landed