Re: Two more RI fast-path issues

On Sat, Oct 17, 2026 at 12:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> There is still something wrong in the RI_FKey stuff. BF animal
> trilobite reported a SIGSEGV in the foreign_key test, and I was able
> to reproduce that locally by compiling HEAD with -DCLOBBER_CACHE_ALWAYS.
> Stack trace looks like
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00000000007770df in _SPI_execute_plan (plan=plan(at)entry=0x184fafc0, options=options(at)entry=0x7fff7819da00, snapshot=snapshot(at)entry=0x0, crosscheck_snapshot=crosscheck_snapshot(at)entry=0x0,
> fire_triggers=fire_triggers(at)entry=false) at spi.c:2498
> 2498 CachedPlanSource *plansource = (CachedPlanSource *) lfirst(lc1);
> (gdb) bt
> #0 0x00000000007770df in _SPI_execute_plan (plan=plan(at)entry=0x184fafc0, options=options(at)entry=0x7fff7819da00, snapshot=snapshot(at)entry=0x0, crosscheck_snapshot=crosscheck_snapshot(at)entry=0x0,
> fire_triggers=fire_triggers(at)entry=false) at spi.c:2498
> #1 0x0000000000778030 in SPI_execute_snapshot (plan=plan(at)entry=0x184fafc0, Values=Values(at)entry=0x7fff7819db00, Nulls=Nulls(at)entry=0x7fff7819dac0 " ", snapshot=snapshot(at)entry=0x0,
> crosscheck_snapshot=crosscheck_snapshot(at)entry=0x0, read_only=read_only(at)entry=false, fire_triggers=false, tcount=1) at spi.c:796
> #2 0x0000000000a1565c in ri_PerformCheck (riinfo=riinfo(at)entry=0x183d6738, qkey=qkey(at)entry=0x7fff7819ddb8, qplan=0x184fafc0, fk_rel=fk_rel(at)entry=0x7f4431f051d0, pk_rel=pk_rel(at)entry=0x7f4431f08190,
> oldslot=oldslot(at)entry=0x0, newslot=0x1847e5a8, is_restrict=false, detectNewRows=false, expect_OK=5) at ri_triggers.c:2723
> #3 0x0000000000a16026 in RI_FKey_check (trigdata=<optimized out>) at ri_triggers.c:535
> #4 0x0000000000a17cdc in RI_FKey_check_ins (fcinfo=0x7fff7819e980) at ri_triggers.c:563
> #5 0x0000000000702b6d in ExecCallTriggerFunc (trigdata=trigdata(at)entry=0x7fff7819eb50, tgindx=tgindx(at)entry=0, finfo=finfo(at)entry=0x1821a620, instr=instr(at)entry=0x0,
> per_tuple_context=per_tuple_context(at)entry=0x18198a80) at trigger.c:2409
> #6 0x0000000000704ed6 in AfterTriggerExecute (estate=<optimized out>, event=0x181a2bec, relInfo=0x1847c9c8, src_relInfo=<optimized out>, dst_relInfo=<optimized out>, trigdesc=0x1821a810,
> finfo=0x1821a620, instr=0x0, per_tuple_context=<optimized out>, trig_tuple_slot1=0x0, trig_tuple_slot2=0x0) at trigger.c:4599
> #7 afterTriggerInvokeEvents (events=events(at)entry=0x180523b0, firing_id=1, estate=estate(at)entry=0x18218960, delete_ok=delete_ok(at)entry=false) at trigger.c:4840
> #8 0x000000000070a01b in AfterTriggerEndQuery (estate=estate(at)entry=0x18218960) at trigger.c:5222
> #9 0x000000000072ff34 in standard_ExecutorFinish (queryDesc=0x18482ac0) at execMain.c:454
> #10 0x000000000092f0d8 in ProcessQuery (plan=<optimized out>, sourceText=0x17fbc450 "INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM generate_series(1, 2);", params=0x0, queryEnv=0x0,
> dest=0x184a2ba8, qc=0x7fff7819ee90) at pquery.c:190
> #11 0x000000000092fbf6 in PortalRunMulti (portal=portal(at)entry=0x18044070, isTopLevel=isTopLevel(at)entry=true, setHoldSnapshot=setHoldSnapshot(at)entry=false, dest=dest(at)entry=0x184a2ba8,
> altdest=altdest(at)entry=0x184a2ba8, qc=qc(at)entry=0x7fff7819ee90) at pquery.c:1273
> #12 0x000000000092ffb7 in PortalRun (portal=portal(at)entry=0x18044070, count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true, dest=dest(at)entry=0x184a2ba8,
> altdest=altdest(at)entry=0x184a2ba8, qc=qc(at)entry=0x7fff7819ee90) at pquery.c:788
> #13 0x000000000092be16 in exec_simple_query (query_string=0x17fbc450 "INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM generate_series(1, 2);") at postgres.c:1297
> #14 0x000000000092d9ad in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4946
> #15 0x0000000000927d5d in BackendMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at backend_startup.c:124
> #16 0x000000000086fb7d in postmaster_child_launch (child_type=<optimized out>, child_slot=4, startup_data=startup_data(at)entry=0x7fff7819f300, startup_data_len=startup_data_len(at)entry=24,
> client_sock=client_sock(at)entry=0x7fff7819f320) at launch_backend.c:268
> #17 0x000000000087331f in BackendStartup (client_sock=0x7fff7819f320) at postmaster.c:3650
> #18 ServerLoop () at postmaster.c:1727
> #19 0x0000000000874c0a in PostmasterMain (argc=argc(at)entry=3, argv=argv(at)entry=0x17fb7e50) at postmaster.c:1414
> #20 0x0000000000532488 in main (argc=3, argv=0x17fb7e50) at main.c:227
> (gdb) p debug_query_string
> $1 = 0x17fbc450 "INSERT INTO fp_reentry_fk SELECT row(1)::fp_vch FROM generate_series(1, 2);"
>
> It looks like something is not prepared for a cached plan to get
> invalidated underneath it.

Thanks for the heads up. Will debug this on Monday.

--
Thanks, Amit Langote