Re: ri_Fast* crash w/ nullable UNIQUE constraint

Hi,

On Thu, Aug 6, 2026 at 11:59 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Aug 6, 2026 at 5:30 AM Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> > I went through v2. 0001, 0002, 0003, 0005 and 0006 look good to me, and
> > I agree with not resetting the context in 0004.
>
> Thanks for checking. I'll push 0001, 0002, 0003, 0005 and 0006
> shortly. 0004 needs more thought first -- see below.

I have now pushed 0001 through 0006 except 0004.

> > One small question on 0004. It adds a MemoryContextDelete to
> > InvalidateConstraintCacheCallBack(), next to the existing pfree(fpmeta).
> > The comment above that function says entries are never removed, only
> > marked invalid, because there may be active references at that point.
> > ri_FastPathFlushArray() and build_index_scankeys() do hold fpmeta, and
> > pointers into it, across the user supplied cast and equality functions.
> > ISTM something must keep an invalidation from arriving there, but I
> > could not work out what. Is that guaranteed somewhere, and would a
> > comment help?
>
> Good question, and the answer is that nothing guarantees it -- you've
> found a live bug. An invalidation really can arrive inside those
> user-supplied functions, and the pfree() that's there today then frees
> fpmeta while ri_FastPathFlushArray() is still reading it and calling
> through FmgrInfos in it. 0004 makes that worse rather than better,
> since MemoryContextDelete() next to the pfree() has the same problem.
> So I'll hold 0004 back for now.
>
> I'd started looking at this from a report off-list and posted it
> separately just before your mail arrived:
>
> https://www.postgresql.org/message-id/CA%2BHiwqFFB6vzx8v3t2%3DrbNYyxMistLf5kkJfqzJ81nadFyLrxA%40mail.gmail.com
>
> Your analysis there is the same as mine, arrived at independently.

Rather than reposting 0004 here, I'll move it to that thread. It now
has to be committed after the fix for the lifetime problem, so I felt
it better to keep the two together than to split them across threads.
I'll note there that it began as 0004 in this thread and that your
review prompted the change.

--
Thanks, Amit Langote