Re: BUG #19476: Segmentation fault in contrib/spi

Ayush Tiwari <ayushtiwari.slg01@gmail.com>

From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pierre.forstmann@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2026-05-14T17:12:07Z
Lists: pgsql-bugs
Hi,

On Thu, 14 May 2026 at 22:15, Nathan Bossart <nathandbossart@gmail.com>
wrote:

> On Thu, May 14, 2026 at 11:01:55AM -0500, Nathan Bossart wrote:
> > Regarding 0001, note that the refint docs state the following:
> >
> >     Note that the primary/unique key columns should be marked NOT NULL
> and
> >     should have a unique index.
> >
> > So maybe we could alternatively teach check_foreign_key() to either ERROR
> > or do nothing instead.  On the other hand, given this case seemed to
> > accidentally work before the CVE fix, it's arguably worth fixing.
>
> Here is what I have staged for commit, which I intend to do shortly.
>
>
Thanks, this version looks good to me.  The compact form is fine, and I
agree with preserving the pre-CVE behavior for this misconfigured case
rather than turning it into an ERROR or no-op.

I also agree with your earlier point about the parameterized 0002: using
the triggered relation's key types for parameters is not generally right
for the referencing relation's SET targets.

I think the cached cascade UPDATE plan issue is worth pursuing,
I'll start a different hackers thread on that
probably using the "don't cache cascade UPDATE plans" approach you
suggested.

Regards,
Ayush

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. refint: Fix segfault in check_foreign_key().

  2. refint: Fix SQL injection and buffer overruns.