Re: scary patch contest

On Wed, Aug 26, 2026 at 1:48 AM Robert Haas <robertmhaas(at)gmail(dot)com> 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