Re: Support a wildcard in backtrace_functions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support a wildcard in backtrace_functions
Дата
Msg-id ZiYFbOsYj5zFJDEj@paquier.xyz
обсуждение исходный текст
Ответ на Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Support a wildcard in backtrace_functions
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: Assert failure in _bt_preprocess_array_keys
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Direct SSL connection with ALPN and HBA rules