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

Hi Fujii-san,

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.

--
Thanks, Amit Langote