Re: Support a wildcard in backtrace_functions

On Mon, 12 Feb 2024 at 14:14, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > The main problem it currently has is that it adds backtraces to all
> > LOG level logs too. So probably we want to make backtrace_functions
> > only log backtraces for ERROR and up (or maybe WARNING/NOTICE and up),
> > or add a backtrace_functions_level GUC too control this behaviour.
>
> A wildcard should IMO only apply for ERROR (and higher) so I've hacked that up
> in the attached v2. I was thinking about WARNING as well but opted against it.

Fine by me patch looks good. Although I think I'd slightly prefer
having a backtrace_functions_level GUC, so that we can get this same
benefit for non wildcard backtrace_functions and so we keep the
behaviour between the two consistent.

> I think we should keep the current functionality and instead adjust the docs.
> This has already been shipped like this, and restricting it now without a clear
> usecase for doing so seems invasive (and someone might very well be using
> this). 0001 in the attached adjusts this.

Would a backtrace_functions_level GUC that would default to ERROR be
acceptable in this case? It's slight behaviour break, but you would be
able to get the previous behaviour very easily. And honestly wanting
to get backtraces for non-ERROR log entries seems quite niche to me,
which to me makes it a weird default.

> + If an log entry is raised and the name of the internal C function where

s/an log entry/a log entry