Re: Support a wildcard in backtrace_functions

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jelte Fennema-Nio <me(at)jeltef(dot)nl>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support a wildcard in backtrace_functions
Date: 2024-04-22 06:36:28
Message-ID: ZiYFbOsYj5zFJDEj@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-22 07:19:53 Re: Direct SSL connection with ALPN and HBA rules
Previous Message Richard Guo 2024-04-22 06:22:25 Re: Assert failure in _bt_preprocess_array_keys