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

On Thu, Oct 22, 2026 at 8:54 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Oct 22, 2026 at 8:16 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > 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.
>
> Sorry, I should also have mentioned that the test case was added as
> part of the fast-path work so it had no chance of running through the
> SPI path before 6aecabcd5.

Given that this is the second report and perhaps others have been
distracted by the red trilobite, I propose to commit the attached
patch, which removes the crashing test case for now. I’ll re-add it
with the commit that fixes the bug causing the crash, which needs a
bit more time to get some details right.

Barring objections, I will commit it first thing tomorrow morning JST
or in about 10 hours. Apologies for not having done this sooner.

--
Thanks, Amit Langote