Re: Support a wildcard in backtrace_functions
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Support a wildcard in backtrace_functions |
Дата | |
Msg-id | CAGECzQQUdunbdK+e_60SAwmfgvvuS9g4x1QthuOBcf_gn5S29g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support a wildcard in backtrace_functions (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Support a wildcard in backtrace_functions
|
Список | pgsql-hackers |
On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut <peter@eisentraut.org> wrote: > Why exactly is this an open item? Is there anything wrong with the > existing feature? The name of the GUC backtrace_on_internal_error is so specific that it's impossible to extend our backtrace behaviour in future releases without adding yet another backtrace GUC. You started the discussion on renaming it upthread: On Fri, 8 Mar 2024 at 15:51, Peter Eisentraut <peter@eisentraut.org> wrote: > What is the relationship of these changes with the recently added > backtrace_on_internal_error? We had similar discussions there, I feel > like we are doing similar things here but slightly differently. Like, > shouldn't backtrace_functions_min_level also affect > backtrace_on_internal_error? Don't you really just want > backtrace_on_any_error? You are sneaking that in through the backdoor > via backtrace_functions. Can we somehow combine all these use cases > more elegantly? backtrace_on_error = {all|internal|none}?
В списке pgsql-hackers по дате отправления: