Re: PG19 FK fast path: OOB write and missed FK checks during batched

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Nikolay Samokhvalov <nik@postgres.ai>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Andrey Borodin <amborodin@acm.org>, Kirk Wolak <wolakk@gmail.com>
Date: 2026-06-11T10:47:39Z
Lists: pgsql-hackers

Attachments

On Thu, Jun 11, 2026 at 6:51 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> On Thu, Jun 11, 2026 at 5:05 PM Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 5:18 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > I only reviewed and applied patch 0001 on my local machine, and it
> > > successfully fixed the crash.
> > >
> > > One minor comment:
> > >
> > > + if (fpentry->flushing)
> > > + {
> > > + ri_FastPathCheck(riinfo, fk_rel, newslot);
> > > + return;
> > > + }
> > >
> > > Would it be worth wrapping the condition with unlikely()? It seems
> > > this branch is expected to be false in most cases, not a strong
> > > opinion though.
> >
> > Good idea.  Will do.
> >
> > Are you planning to look at 0002?
>
> I just applied 0002 and ran the regression successfully.
>
> I have one trivial comment, subXact abort doesn't NULL the
> ri_fastpath_cache, so I think the following comment of
> RI_FastPathEntry should be polished accordingly by removing the
> `SubXactCallback`.
>
> * ri_FastPathEndBatch(); on abort, ResourceOwner releases the cached
> * relations and the XactCallback/SubXactCallback NULL the static cache pointer
> * to prevent any subsequent access.

Thanks for the review.  Yes, I missed that.

I've updated the patches to address your comments and did some other polishing.


--
Thanks, Amit Langote

Commits

  1. Confine RI fast-path batching to the top transaction level

  2. Fix out-of-bounds write in RI fast-path batch on re-entry

  3. Stamp 19beta1.