On Thu, Oct 22, 2026 at 8:54 PM Amit Langote <[email protected]> wrote: > On Thu, Oct 22, 2026 at 8:16 PM Amit Langote <[email protected]> wrote: > > On Thu, Oct 22, 2026 at 8:09 PM Amit Langote <[email protected]> > > wrote: > > > On Thu, Oct 22, 2026 at 6:18 PM Fujii Masao <[email protected]> wrote: > > > > On Thu, Oct 15, 2026 at 5:07 PM Amit Langote <[email protected]> > > > > 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_9cm...@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-g2dqxafvkfer...@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
From 1ef63b82d1bb7dde514d86624f9ba73cb226da6b Mon Sep 17 00:00:00 2001 From: Amit Langote <[email protected]> Date: Thu, 22 Oct 2026 22:00:07 +0900 Subject: [PATCH v1] Temporarily remove a test case that hits an unfixed bug Buildfarm animal trilobite turned red because the test that is being removed crashes due to a long-standing bug in how ri_FetchPreparedPlan() handles an invalid SPI plan, which the test started reaching after 6aecabcd5ed made it go through the SPI path and which CLOBBER_CACHE_ALWAYS exposes. Fixing that bug will take some time, so in the meantime remove the test case so the buildfarm can turn green and other committers are not distracted by this. The test will be re-added with the commit to fix the bug. Reported-by: Tom Lane <[email protected]> Reported-by: Fujii Masao <[email protected]> Discussion: [email protected]">https://postgr.es/m/[email protected] Discussion: https://posgre.es/m/CA+HiwqE=QFc7xS72xZ5scFNUbLdOCJyvew+3toLebsWipJOqnQ@mail.gmail.com --- src/test/regress/expected/foreign_key.out | 27 ----------------------- src/test/regress/sql/foreign_key.sql | 22 ------------------ 2 files changed, 49 deletions(-) diff --git a/src/test/regress/expected/foreign_key.out b/src/test/regress/expected/foreign_key.out index b1f36f6a1bb..a2f37c6d153 100644 --- a/src/test/regress/expected/foreign_key.out +++ b/src/test/regress/expected/foreign_key.out @@ -4021,33 +4021,6 @@ DETAIL: Key (a)=(999) is not present in table "fp_pk_dom". INSERT INTO fp_fk_dom VALUES (NULL); DROP TABLE fp_fk_dom, fp_pk_dom; DROP DOMAIN fp_int8dom; --- Re-entrant FK check: DML on the same FK table from a cast function -CREATE TABLE fp_reentry_pk (id int PRIMARY KEY); -INSERT INTO fp_reentry_pk VALUES (1), (2); -CREATE TYPE fp_vch AS (v int); -CREATE FUNCTION fp_vcast(fp_vch) RETURNS int LANGUAGE plpgsql AS $$ -BEGIN - IF $1.v = 1 THEN - INSERT INTO fp_reentry_fk VALUES (row(2)::fp_vch); - END IF; - RETURN $1.v; -END$$; -CREATE CAST (fp_vch AS int) WITH FUNCTION fp_vcast(fp_vch) AS IMPLICIT; -CREATE TABLE fp_reentry_fk (a fp_vch - REFERENCES fp_reentry_pk (id)); --- cast re-enters with DML on the same FK -INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM generate_series(1, 2); -SELECT a, count(*) FROM fp_reentry_fk GROUP BY a ORDER BY a; - a | count ------+------- - (1) | 2 - (2) | 2 -(2 rows) - -DROP TABLE fp_reentry_fk, fp_reentry_pk; -DROP CAST (fp_vch AS int); -DROP FUNCTION fp_vcast(fp_vch); -DROP TYPE fp_vch; -- -- Cache invalidation arriving during a fast-path check. -- diff --git a/src/test/regress/sql/foreign_key.sql b/src/test/regress/sql/foreign_key.sql index 99ea110e848..5525c0f90c8 100644 --- a/src/test/regress/sql/foreign_key.sql +++ b/src/test/regress/sql/foreign_key.sql @@ -2979,28 +2979,6 @@ INSERT INTO fp_fk_dom VALUES (NULL); DROP TABLE fp_fk_dom, fp_pk_dom; DROP DOMAIN fp_int8dom; --- Re-entrant FK check: DML on the same FK table from a cast function -CREATE TABLE fp_reentry_pk (id int PRIMARY KEY); -INSERT INTO fp_reentry_pk VALUES (1), (2); -CREATE TYPE fp_vch AS (v int); -CREATE FUNCTION fp_vcast(fp_vch) RETURNS int LANGUAGE plpgsql AS $$ -BEGIN - IF $1.v = 1 THEN - INSERT INTO fp_reentry_fk VALUES (row(2)::fp_vch); - END IF; - RETURN $1.v; -END$$; -CREATE CAST (fp_vch AS int) WITH FUNCTION fp_vcast(fp_vch) AS IMPLICIT; -CREATE TABLE fp_reentry_fk (a fp_vch - REFERENCES fp_reentry_pk (id)); --- cast re-enters with DML on the same FK -INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM generate_series(1, 2); -SELECT a, count(*) FROM fp_reentry_fk GROUP BY a ORDER BY a; -DROP TABLE fp_reentry_fk, fp_reentry_pk; -DROP CAST (fp_vch AS int); -DROP FUNCTION fp_vcast(fp_vch); -DROP TYPE fp_vch; - -- -- Cache invalidation arriving during a fast-path check. -- -- 2.47.3
