Re: Support a wildcard in backtrace_functions

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Jelte Fennema-Nio <me(at)jeltef(dot)nl>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-03-08 16:17:26
Message-ID: CALj2ACUz9fTHdotjyUWh=oqamMBM1yNY19FSj7fUrbf2a8ndtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 8, 2024 at 9:25 PM Jelte Fennema-Nio <me(at)jeltef(dot)nl> wrote:
>
> 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?
>
> I think that's a reasonable question. And the follow up ones too.
>
> 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.

Hm, we may not want backtrace_on_internal_error to be on by default.
AFAICS, all ERRCODE_INTERNAL_ERROR are identifiable with the error
message, so it's sort of easy for one to track down the cause of it
without actually needing to log backtrace by default.

On Fri, Mar 8, 2024 at 8:21 PM 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}?

I see a merit in Peter's point. I like the idea of
backtrace_functions_min_level controlling backtrace_on_internal_error
too. Less GUCs for similar functionality is always a good idea IMHO.
Here's what I think:

1. Rename the new GUC backtrace_functions_min_level to backtrace_min_level.
2. Add 'internal' to backtrace_min_level_options enum
+static const struct config_enum_entry backtrace_functions_level_options[] = {
+ {"internal", INTERNAL, false},
+ {"debug5", DEBUG5, false},
+ {"debug4", DEBUG4, false},
3. Remove backtrace_on_internal_error GUC which is now effectively
covered by backtrace_min_level = 'internal';

Does anyone see a problem with it?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-03-08 16:31:11 Re: Confine vacuum skip logic to lazy_scan_skip
Previous Message Heikki Linnakangas 2024-03-08 16:07:33 Re: Confine vacuum skip logic to lazy_scan_skip