Re: Support a wildcard in backtrace_functions

On Wed, 15 May 2024 at 20:31, Robert Haas <robertmhaas@gmail.com> wrote:
> That's fine, except that I think that what the previous discussion
> revealed is that we don't have consensus on how backtrace behavior
> ought to be controlled: backtrace_on_internal_error was one proposal,
> and this was a competing proposal, and neither one of them seemed to
> be completely satisfactory.

Attached is a rebased patchset of my previous proposal, including a
few changes that Michael preferred:
1. Renames log_backtrace to log_backtrace_mode
2. Rename internal to internal_error

I reread the thread since I previously posted the patch and apart from
Michaels feedback I don't think there was any more feedback on the
current proposal.

Rethinking about it myself though, I think the main downside of this
proposal is that if you want the previous behaviour of
backtrace_functions (add backtraces to all elog/ereports in the given
functions) you now need to set three GUCs:
log_backtrace_mode='all'
backtrace_functions='some_func'
backtrace_min_level=DEBUG5

The third one is not needed in the common case where someone only
cares about errors, but still needing to set log_backtrace_mode='all'
might seem a bit annoying. One way around that would be to make
log_backtrace_mode and backtrace_functions be additive instead of
subtractive.

Personally I think the proposed subtractive nature would be exactly
what I want for backtraces I'm interested in. Because I would want to
use backtrace_functions in this way:

1. I see an error I want a backtrace of: et log_backtrace_mode='all'
and try to trigger again.
2. Oops, there's many backtraces now let's filter by function: set
backtrace_functions=some_func

So if it's additive, I'd have to also undo log_backtrace_mode='all'
again at step 2. So changing two GUCs instead of one to do what I
want.