Re: Support a wildcard in backtrace_functions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support a wildcard in backtrace_functions
Date
Msg-id ZiYFbOsYj5zFJDEj@paquier.xyz
Whole thread Raw
In response to Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Support a wildcard in backtrace_functions
List pgsql-hackers
On Sun, Apr 21, 2024 at 09:26:38AM +0200, Peter Eisentraut wrote:
> Note that a standard test run produces a number of internal errors.  I
> haven't checked how likely these are in production, but one might want to
> consider that before starting to dump backtraces in routine situations.
>
> For example,
>
> $ PG_TEST_INITDB_EXTRA_OPTS='-c backtrace_on_internal_error=on' meson test
> -C build
> $ grep -r 'BACKTRACE:' build/testrun | wc -l
> 85

Ugh, I would not have expected that much.  Isn't the problem you are
reporting here entirely unrelated, though?  It seems to me that these
error paths should be using a proper errcode rather than the internal
errcode, as these refer to states that can be reached by the user with
a combination of queries and/or cancellations.

For example, take this one for the REFRESH matview path which is a
valid error, still using an elog():
    if (!foundUniqueIndex)
        elog(ERROR, "could not find suitable unique index on materialized view");

I'd like to think about this stuff in a different way: this is useful
if enabled by default because it can also help in finding out error
paths that should not use the internal errcode.  Normally, there
should be zero backtraces produced, except in unexpected
never-to-be-reached cases.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Assert failure in _bt_preprocess_array_keys
Next
From: Michael Paquier
Date:
Subject: Re: Direct SSL connection with ALPN and HBA rules