Re: Support a wildcard in backtrace_functions

On Fri, Mar 8, 2024 at 7:12 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 8 Mar 2024, at 12:25, Jelte Fennema-Nio <me(at)jeltef(dot)nl> wrote:
> >
> > On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> >>
> >> On 2024-Mar-08, Bharath Rupireddy wrote:
> >>
> >>> This works only if '* 'is specified as the only one character in
> >>> backtrace_functions = '*', right? If yes, what if someone sets
> >>> backtrace_functions = 'foo, bar, *, baz'?
> >>
> >> It throws an error, as expected. This is a useless waste of resources:
> >> checking for "foo" and "bar" is pointless, since the * is going to give
> >> a positive match anyway. And the "baz" is a waste of memory which is
> >> never going to be checked.
> >
> > Makes sense. Attached is a new patchset that implements it that way.
>
> This version address the concerns raised by Alvaro, and even simplifies the
> code over earlier revisions. My documentation comments from upthread still
> stands, but other than those this version LGTM.

So, to get backtraces of all functions at
backtrace_functions_min_level level, one has to specify
backtrace_functions = '*'; combining it with function names is not
allowed. This looks cleaner.

postgres=# ALTER SYSTEM SET backtrace_functions = '*, pg_create_restore_point';
ERROR: invalid value for parameter "backtrace_functions": "*,
pg_create_restore_point"
DETAIL: Invalid character

I have one comment on 0002, otherwise all looks good.

+ <para>
+ A single <literal>*</literal> character can be used instead of a list
+ of C functions. This <literal>*</literal> is interpreted as a wildcard
+ and will cause all errors in the log to contain backtraces.
+ </para>

It's not always the ERRORs for which backtraces get logged, it really
depends on the new GUC backtrace_functions_min_level. If my
understanding is right, can we specify that in the above note?

> > I've not included Bharath his 0003 patch, since it's a much bigger
> > change than the others, and thus might need some more discussion.

+1. I'll see if I can start a new thread for this.

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