| From: | Jelte Fennema-Nio <me(at)jeltef(dot)nl> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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-18 09:54:23 |
| Message-ID: | CAGECzQQUdunbdK+e_60SAwmfgvvuS9g4x1QthuOBcf_gn5S29g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut <peter(at)eisentraut(dot)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(at)eisentraut(dot)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}?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2024-04-18 10:03:45 | Re: WIP Incremental JSON Parser |
| Previous Message | Tomas Vondra | 2024-04-18 09:39:22 | Re: BitmapHeapScan streaming read user and prelim refactoring |