On Wed, Aug 26, 2026 at 1:48 AM Robert Haas <[email protected]> wrote: > I asked Claude to evaluate which v19 patches were the scariest based > on the number and type of bugs fixed post-freeze. Results below, with > a few particularly cutting remarks from the LLM edited out. I also > omitted the list of runners-up that it generated, none of which seemed > to me to be of enough concern to be worth discussion. I do think these > are worth discussing, though: are any of them likely to still be in > bad enough shape that we should consider reverting them before v19 > ships? Past performance is no guarantee of future results, but it's > not a contraindication either. > > 1. RI fast-path FK checks / batching (2da86c1ef9b, b7b27eb41a5, > Junwang Zhao and Amit Langote): ~16 fixes including an out-of-bounds > write on re-entry, a crash under nested SPI, a wrong-user-id index > scan, and five distinct classes of incorrect FK enforcement > (cross-type, domains, column order, nullable keys, non-btree indexes). > The transactional design was retrofitted post-freeze > (subtransaction/firing-cycle tracking, deferred-trigger integration, > xact.c cleanup).
I think the RI fast-path work deserves the scrutiny. Looking through the follow-up fixes, I think I underestimated the lifecycle and re-entrancy complexity involved in batching fast-path foreign key checks within trigger.c. Several of the post-freeze fixes have been consequences of that, and I just started working on another re-entrancy crash involving SET CONSTRAINTS ... IMMEDIATE [1]. I should have done more systematic testing before committing the batching work. I am considering building a generated test harness now, particularly to look for dropped FK checks caused by losing track of batched checks. This will help decide whether the batching layer is still in good enough shape for v19 or whether I should propose reverting it while keeping the simpler non-batched fast path. If getting enough confidence from that exercise looks likely to take much of the time remaining before RC1, I think that should weigh in favor of reverting at least the batching portion. Since I committed this work, I don't think my confidence in the fixes should settle the question. I'll report what I find, but would welcome other views now too, including whether further testing is worth doing at this point or whether I should just prepare the revert. -- Thanks, Amit Langote [1] https://www.postgresql.org/message-id/CA%2BHiwqE2MRym5fGfxz58AdzxEzXyDuE4SEpM3eoH3HCii%3DWh%3DA%40mail.gmail.com
