Re: Support a wildcard in backtrace_functions

On Wed, Apr 10, 2024 at 11:07:00AM +0200, Jelte Fennema-Nio wrote:
> I think patch 0002 should be considered an Open Item for PG17. Since
> it's proposing changing the name of the newly introduced
> backtrace_on_internal_error GUC. If we want to change it in this way,
> we should do it before the release and preferably before the beta.

Indeed, it makes little sense to redesign this at the beginning of v18
if we're unhappy with the current outcome of v17. So tweaking that is
worth considering at this stage.

log_backtrace speaks a bit more to me as a name for this stuff because
it logs a backtrace. Now, there is consistency on HEAD as well
because these GUCs are all prefixed with "backtrace_". Would
something like a backtrace_mode where we have an enum rather than a
boolean be better? One thing would be to redesign the existing GUC as
having two values on HEAD as of:
- "none", to log nothing.
- "internal", to log backtraces for internal errors.

Then this could be extended with more modes, to discuss in future
releases as new features.

What you are suggesting with backtrace_min_level is an entirely new
feature. Perhaps using an extra GUC to control the interactions of
the modes that can be assigned to the primary GUC "log_backtrace" in
your 0002 is better, but all that sounds like v18 material at this
stage. The code that resolves the interactions between the existing
GUC and the new "level" GUC does not use LOGBACKTRACE_ALL. Perhaps it
should use a case/switch.

+ gettext_noop("Each level includes all the levels that follow it. The later"
+ " the level, the fewer backtraces are created."),

> I added it to the Open Items list[1] so we don't forget to at least
> decide on this.
>
> [1]: https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items

Thanks.
--
Michael