Re: PG19 FK fast path: OOB write and missed FK checks during batched
Junwang Zhao <zhjwpku@gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
To: Amit Langote <amitlangote09@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-11T09:50:51Z
Lists: pgsql-hackers
Hi Amit,
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, Amit Langote
--
Regards
Junwang Zhao
Commits
-
Confine RI fast-path batching to the top transaction level
- 4113873a5ab0 19 (unreleased) landed
-
Fix out-of-bounds write in RI fast-path batch on re-entry
- 0e47bb5fbeec 19 (unreleased) landed
-
Stamp 19beta1.
- 4b0bf0788b06 19 (unreleased) cited