On Thu, Oct 22, 2026 at 10:14 PM Amit Langote <[email protected]> wrote: > 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.
Done. I understand a trilobite run takes a while to complete, but hopefully it picks up the commit and turns green sooner rather than later. -- Thanks, Amit Langote
