Support a wildcard in backtrace_functions

From: Jelte Fennema-Nio <me(at)jeltef(dot)nl>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Support a wildcard in backtrace_functions
Date: 2023-12-20 11:23:04
Message-ID: CAGECzQTpdujCEt2SH4DBwRLoDq4HJArGDaxJSsWX0G=tNnzaVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I would like to be able to add backtraces to all ERROR logs. This is
useful to me, because during postgres or extension development any
error that I hit is usually unexpected. This avoids me from having to
change backtrace_functions every time I get an error based on the
function name listed in the LOCATION output (added by "\set VERBOSITY
verbose").

Attached is a trivial patch that starts supporting
backtrace_functions='*'. By setting that in postgresql.conf for my dev
environment it starts logging backtraces always.

The main problem it currently has is that it adds backtraces to all
LOG level logs too. So probably we want to make backtrace_functions
only log backtraces for ERROR and up (or maybe WARNING/NOTICE and up),
or add a backtrace_functions_level GUC too control this behaviour. The
docs of backtrace_functions currently heavily suggest that it should
only be logging backtraces for errors, so either we actually start
doing that or we should clarify the docs (emphasis mine):

> This parameter contains a comma-separated list of C function
> names. If an **error** is raised and the name of the internal C function
> where the **error** happens matches a value in the list, then a
> backtrace is written to the server log together with the error
> message. This can be used to debug specific areas of the
> source code.

Attachment Content-Type Size
v1-0001-Add-wildcard-support-to-backtrace_functions-GUC.patch application/x-patch 2.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-12-20 11:35:38 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Matthias van de Meent 2023-12-20 11:14:32 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements