Re: PG19: two RI fast-path issues found while testing the batching revert

On Thu, Oct 22, 2026 at 8:09 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Oct 22, 2026 at 6:18 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >
> > On Thu, Oct 15, 2026 at 5:07 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > > No, they have not. I’ll commit these today.
> > >
> > > Done, sorry for the delay.
> >
> > Commit 6aecabcd5ed seems to have caused a test failure on buildfarm
> > member trilobite [1]. The log indicates that a client backend crashed
> > with a segmentation fault:
> >
> > 2026-10-22 10:03:23.907 CEST [13117:8] LOG: client backend (PID
> > 16078) was terminated by signal 11: Segmentation fault
> > 2026-10-22 10:03:23.907 CEST [13117:9] DETAIL: Failed process was
> > running: INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM
> > generate_series(1, 2);
> >
> > Codex came up with the following minimal reproduction:
> >
> > --------------------------------------------------
> > SET debug_discard_caches = 1;
> >
> > CREATE TABLE p (id int PRIMARY KEY);
> > INSERT INTO p VALUES (1), (2);
> > CREATE TYPE t AS (v int);
> >
> > CREATE FUNCTION c(t) RETURNS int LANGUAGE plpgsql AS $$
> > BEGIN
> > IF $1.v = 1 THEN
> > INSERT INTO f VALUES (ROW(2)::t);
> > END IF;
> > RETURN $1.v;
> > END$$;
> >
> > CREATE CAST (t AS int) WITH FUNCTION c(t) AS IMPLICIT;
> > CREATE TABLE f (a t REFERENCES p);
> > INSERT INTO f VALUES (ROW(1)::t);
> > --------------------------------------------------
> >
> > This issue should be added into Open Items for v19?
>
> It's actually an old bug affecting all stable releases as I explained in:
> https://postgr.es/m/CA+HiwqGZ9Rx5Lkh8+or4HK+jjHKQTZCgwgL50J=0mqL_9Cmu7g@mail.gmail.com
>
> Tom reported that same trilobite failure there.
>
> The patch for the same issue though with a different crashing example
> is also being discussed here:
> https://postgr.es/m/CA+HiwqGjcSqmsruvq94V0ARNx0Gec6Va9J-G2DQXafVKfEravQ@mail.gmail.com
>
> I am about to post a new patch at the second thread.

To clarify, the test case that crashed trilobite started going through
the SPI path instead of the fast path with 6aecabcd5ed. The SPI path
has a bug that causes the crash, but the fast path doesn’t have the
same bug. So the issue was not found until that commit made the test
start going through the SPI path.

--
Thanks, Amit Langote