Re: Eliminating SPI / SQL from some RI triggers - take 3 - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Eliminating SPI / SQL from some RI triggers - take 3
Date
Msg-id CA+HiwqETMt=g7BHx3Hf+H4Rtpw836+65O5dwgTaCAWqd_N4UoQ@mail.gmail.com
Whole thread
In response to Re: Eliminating SPI / SQL from some RI triggers - take 3  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Wed, Apr 8, 2026 at 10:23 AM Amit Langote <amitlangote09@gmail.com> wrote:
> On Tue, Apr 7, 2026 at 10:00 PM Evan Montgomery-Recht
> <montge@mianetworks.net> wrote:
> > Unrelated to my patch, SonarCloud flagged a potential issue in
> > recheck_matched_pk_tuple() (line 3370): the function loops over
> > ii_NumIndexKeyAttrs elements of the skeys array, but the caller in
> > ri_FastPathFlushArray passes recheck_skey[1] -- an array of exactly
> > one element. This is safe because ri_FastPathFlushArray is the
> >
> > single-column FK path, so ii_NumIndexKeyAttrs is always 1 there.
> > However, the function signature doesn't communicate this constraint,
> > which flags as CWE-125 (out-of-bounds read) / CERT C ARR30-C. Adding
> > an nkeys parameter (like ri_FastPathProbeOne already has) would make
> > the contract explicit.
>
> Makes sense.  Will push the attached patch for this.

Pushed this fix.

--
Thanks, Amit Langote



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Evgeny Voropaev
Date:
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm