Re: Support a wildcard in backtrace_functions

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 19, 2024 at 2:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've not been following this thread, so I don't have an opinion
>> about what the design ought to be.  But if we still aren't settled
>> on it by now, I think the prudent thing is to revert the feature
>> out of v17 altogether, and try again in v18.  When we're still
>> designing something after feature freeze, that is a good indication
>> that we are trying to ship something that's not ready for prime time.

> There are two features at issue here. One is
> backtrace_on_internal_error, committed as
> a740b213d4b4d3360ad0cac696e47e5ec0eb8864. The other is a feature to
> produce backtraces for all errors, which was originally proposed as
> backtrace_functions='*', backtrace_functions_level=ERROR but which has
> subsequently been proposed with a few other spellings that involve
> merging that functionality into backtrace_on_internal_error. To the
> extent that there's an open question here for PG17, it's not about
> reverting this patch (which AIUI has never been committed) but about
> reverting the earlier patch for backtrace_on_internal_error. So is
> that the right thing to do?

I can't say that I care for "backtrace_on_internal_error".
Re-reading that thread, I see I argued for having *no* GUC and
just enabling that behavior all the time.  I lost that fight,
but it should have been clear that a GUC of this exact shape
is a design dead end --- and that's what we're seeing now.

> Well, on the one hand, I confess to having had a passing thought that
> backtrace_on_internal_error is awfully specific. Surely, user A's
> criterion for which messages should have backtraces might be anything,
> and we cannot reasonably add backtrace_on_$WHATEVER for all $WHATEVER
> in some large set. And the debate here suggests that I wasn't the only
> one to have that concern. So that argues for a revert.

Exactly.

> But on the other hand, in my personal experience,
> backtrace_on_internal_error would be the right thing in a really large
> number of cases.

That's why I thought we could get away with doing it automatically.
Sure, more control would be better.  But if we just hard-wire it for
the moment then we aren't locking in what the eventual design for
that control will be.

            regards, tom lane