Re: Support a wildcard in backtrace_functions

On Mon, Apr 22, 2024 at 09:25:15AM -0400, Robert Haas wrote:
> That's long been my feeling about this. So, if we revert this for now,
> what we ought to do is put it back right ASAP after feature freeze and
> then clean all that up.

In the 85 backtraces I can find in the tests, we have a mixed bag of:
- Code paths that use the internal errcode, but should not.
- Code paths that use the internal errcode, and are OK with that in
the scope of the tests.
- Code paths that use the internal errcode, though the coding
assumptions behind their use feels fuzzy to me, like amcheck for some
SQL tests or satisfies_hash_partition() in one SQL test.

As cleaning up that is a separate topic, I have begun a new thread and
with a full analysis of everything I've spotted. See here:
https://www.postgresql.org/message-id/Zic_GNgos5sMxKoa@paquier.xyz

The first class of issues refers to real problems, and should be
assigned errcodes. Having a way to switch the backtraces off can have
some benefits in the second cases. However, even if we silence them,
it would also mean to miss backtraces that could be legit. The third
cases would require a different analysis, behind the designs of the
code paths able to trigger the internal codes.

At this stage, my opinion would tend in favor of a revert of the GUC.
The second class of cases is useful to stress many unexpected cases,
and I don't expect this number to go down over time, but increase with
more advanced tests added into core (I/O failures with partial writes
for availability, etc).
--
Michael