Re: Support a wildcard in backtrace_functions - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Support a wildcard in backtrace_functions
Date
Msg-id CALj2ACVwYOfBnsmuWpR4a=hiFqSHhJ2dtiDbMrphEZ1edfSKtg@mail.gmail.com
Whole thread Raw
In response to Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Wed, Mar 13, 2024 at 7:50 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> > I think it all depends on how close we consider
> > backtrace_on_internal_error and backtrace_functions. While they
> > obviously have similar functionality, I feel like
> > backtrace_on_internal_error is probably a function that we'd want to
> > turn on by default in the future. While backtrace_functions seems like
> > it's mostly useful for developers. (i.e. the current grouping of
> > backtrace_on_internal_error under DEVELOPER_OPTIONS seems wrong to me)
>
> Hence the idea
>
>      backtrace_on_error = {all|internal|none}
>
> which could default to 'internal'.

So, are you suggesting to just have backtrace_on_error =
{all|internal|none} leaving backtrace_functions_min_level aside?

In that case, I'd like to understand how backtrace_on_error and
backtrace_functions interact with each other? Does one need to set
backtrace_on_error = all to get backtrace of functions specified in
backtrace_functions?

What must be the behaviour of backtrace_on_error = all?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: meson vs tarballs
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Support a wildcard in backtrace_functions