Re: Support a wildcard in backtrace_functions

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Jelte Fennema-Nio <me(at)jeltef(dot)nl>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Support a wildcard in backtrace_functions
Date: 2024-02-29 10:35:21
Message-ID: 202402291035.op26n4voqmba@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-Feb-28, Jelte Fennema-Nio wrote:

> diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
> index 699d9d0a241..553e4785520 100644
> --- a/src/backend/utils/error/elog.c
> +++ b/src/backend/utils/error/elog.c
> @@ -843,6 +843,8 @@ matches_backtrace_functions(const char *funcname)
> if (*p == '\0') /* end of backtrace_function_list */
> break;
>
> + if (strcmp("*", p) == 0)
> + return true;
> if (strcmp(funcname, p) == 0)
> return true;
> p += strlen(p) + 1;

Hmm, so if I write "foo,*" this will work but check all function names
first and on the second entry. But if I write "foo*" the GUC value will
be accepted but match nothing (as will "*foo" or "foo*bar"). I don't
like either of these behaviors. I think we should tighten this up: an
asterisk should be allowed only if it appears alone in the string
(short-circuiting check_backtrace_functions before strspn); and let's
leave the strspn() call alone.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree. (Don Knuth)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-02-29 10:46:42 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Previous Message jian he 2024-02-29 10:30:17 Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);