MIME-Version: 1.0
References: 
 <CAM527d9exRCdWrhJOnAxk_vACg7sr_yPoaJp_+uCFY0qP8v=aw@mail.gmail.com>
 <CA+HiwqGTOwRqkgrhqq6-nLyVGfGuAHMfoo+Ob2A4Z98ZkgwCmg@mail.gmail.com>
 <CA+HiwqGWUtxc7KECuT06aYTiwwxGBxM89qY_W64dQjYEoziXog@mail.gmail.com>
 <CA+HiwqHUz50YqJn4XiNsSLN2c+9eYBy1af=y_dfdJTsz5BmbJg@mail.gmail.com>
 <CAM527d_2OpJ3KCOT1QqGh4neCPpgZTgM+VUxTqVgOSweOzTDQw@mail.gmail.com>
 <CA+HiwqFBXTTy3KcfGVxqxkhX5zV99R7=s2EwkxMiiWnVbyTpyw@mail.gmail.com>
 <CAJTYsWVgHCNDZb2F62F+aELnKJO2BWtHaAXcN-AmgPPP+GAnUQ@mail.gmail.com>
 <CA+HiwqELE-eyOfBBEmpr_eGf-04PUvZg5BjypW2CMHbed5QGhA@mail.gmail.com>
 <CAEG8a3JhZwvdeedTvQCvvXgVkeb6ENW2haiHfxnXkXbv3NMmjg@mail.gmail.com>
 <CA+HiwqG4Psv+777t8FsSpOTtMeqgBYTYfD8EXHYQmCwVcprC_g@mail.gmail.com>
In-Reply-To: 
 <CA+HiwqG4Psv+777t8FsSpOTtMeqgBYTYfD8EXHYQmCwVcprC_g@mail.gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
Date: Thu, 11 Jun 2026 17:50:51 +0800
Message-ID: 
 <CAEG8a3L6avXJNnk1BBZZvDG8dR15FWZdK8RALuZ4SLpgXTw3xg@mail.gmail.com>
Subject: Re: PG19 FK fast path: OOB write and missed FK checks during batched
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAEG8a3L6avXJNnk1BBZZvDG8dR15FWZdK8RALuZ4SLpgXTw3xg%40mail.gmail.com>
Precedence: bulk

Hi Amit,

On Thu, Jun 11, 2026 at 5:05=E2=80=AFPM Amit Langote <amitlangote09@gmail.c=
om> wrote:
>
> On Thu, Jun 11, 2026 at 5:18=E2=80=AFPM 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 poin=
ter
* to prevent any subsequent access.

>
> --
> Thanks, Amit Langote


--=20
Regards
Junwang Zhao