Re: Support a wildcard in backtrace_functions

On Fri, Apr 19, 2024 at 7:31 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> While there maybe isn't consensus on what a new design exactly looks
> like, I do feel like there's consensus on this thread that the
> backtrace_on_internal_error GUC is almost certainly not the design
> that we want. I guess a more conservative approach to this problem
> would be to revert the backtrace_on_internal_error commit and agree on
> a better design for PG18. But I didn't think that would be necessary
> if we could agree on the name for a more flexibly named GUC, which
> seemed quite possible to me (after a little bit of bikeshedding).

I think Peter is correct that this presupposes we more or less agree
on the final destination. For example, I think that log_backtrace =
error | internal | all is a bit odd; why not backtrace_errcodes =
<comma-separated list of error codes>? I've written a logging hook for
EDB that can filter out error messages by error code, so I don't think
it's at all a stretch to think that someone might want to do something
similar here. I agree that it's somewhat likely that the name we want
going forward isn't backtrace_on_internal_error, but I don't think we
know that completely for certain, or what new name we necessarily
want.

> I think releasing a GUC (even if it's just meant for developers) in
> PG17 and then deprecating it for a newer version in PG18 wouldn't be a
> great look. And even if that's not a huge problem, it still seems
> better not to have the problem at all. Renaming the GUC now seems to
> have only upsides to me: worst case the new design turns out not to be
> what we want either, and we have to deprecate the GUC. But in the best
> case we don't need to deprecate anything.

There are some things that are pretty hard to change once we've
released them. For example, if we had a function or operator and
somebody embeds it in a view definition, removing or renaming it
prevents people from upgrading. But GUCs are not as bad. If you don't
port your postgresql.conf forward to the new version, or if you
haven't uncommented this particular setting, then there's no issue at
all, and when there is a problem, removing a GUC setting from
postgresql.conf is pretty straightforward compared to getting some
construct out of your application code. I agree it's not amazing if we
end up changing this exactly one release after it was introduced, but
we don't really know that we're going to change it next release, or at
all, and even if we do, I still don't think that's a catastrophe.

I'm not completely certain that "let's just leave this alone for right
now" is the correct conclusion, but the fact that we might need to
rename a GUC down the road is not, by itself, a critical flaw in the
status quo.

--
Robert Haas
EDB: http://www.enterprisedb.com