Re: Support a wildcard in backtrace_functions

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: Support a wildcard in backtrace_functions
Дата
Msg-id CAGECzQTooa00GyibgyL=sJjbpsj+o9PDM+1EVcj9P45rcCd_zQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Support a wildcard in backtrace_functions  (Jelte Fennema-Nio <me@jeltef.nl>)
Список pgsql-hackers
On Wed, 13 Mar 2024 at 15:20, Peter Eisentraut <peter@eisentraut.org> wrote:
> Hence the idea
>
>      backtrace_on_error = {all|internal|none}
>
> which could default to 'internal'.

I think one use-case that I'd personally at least would like to see
covered is being able to get backtraces on all warnings. How would
that be done with this setting?

backtrace_on_error = all
backtrace_min_level = warning

In that case backtrace_on_error seems like a weird name, since it can
include backtraces for warnings if you change backtrace_min_level. How
about the following aproach. It still uses 3 GUCs, but they now all
work together. There's one entry point and two additional filters
(level and function name)

# Says what log entries to log backtraces for
log_backtrace = {all|internal|none} (default: internal)

# Excludes log entries from log_include_backtrace by level
backtrace_min_level = {debug4|...|fatal} (default: error)

# Excludes log entries from log_include_backtrace if function name
# does not match list, but empty string disables this filter (thus
# logging for all functions)
backtrace_functions = {...} (default: '')


PS. Other naming option for log_backtrace could be log_include_backtrace



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Support a wildcard in backtrace_functions
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: BitmapHeapScan streaming read user and prelim refactoring