On Fri, Apr 19, 2024 at 7:31 AM Jelte Fennema-Nio <m...@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
