On Sat, Oct 17, 2026 at 12:17 AM Tom Lane <[email protected]> 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@entry=0x184fafc0, 
> options=options@entry=0x7fff7819da00, snapshot=snapshot@entry=0x0, 
> crosscheck_snapshot=crosscheck_snapshot@entry=0x0,
>     fire_triggers=fire_triggers@entry=false) at spi.c:2498
> 2498                    CachedPlanSource *plansource = (CachedPlanSource *) 
> lfirst(lc1);
> (gdb) bt
> #0  0x00000000007770df in _SPI_execute_plan (plan=plan@entry=0x184fafc0, 
> options=options@entry=0x7fff7819da00, snapshot=snapshot@entry=0x0, 
> crosscheck_snapshot=crosscheck_snapshot@entry=0x0,
>     fire_triggers=fire_triggers@entry=false) at spi.c:2498
> #1  0x0000000000778030 in SPI_execute_snapshot (plan=plan@entry=0x184fafc0, 
> Values=Values@entry=0x7fff7819db00, Nulls=Nulls@entry=0x7fff7819dac0 " ", 
> snapshot=snapshot@entry=0x0,
>     crosscheck_snapshot=crosscheck_snapshot@entry=0x0, 
> read_only=read_only@entry=false, fire_triggers=false, tcount=1) at spi.c:796
> #2  0x0000000000a1565c in ri_PerformCheck (riinfo=riinfo@entry=0x183d6738, 
> qkey=qkey@entry=0x7fff7819ddb8, qplan=0x184fafc0, 
> fk_rel=fk_rel@entry=0x7f4431f051d0, pk_rel=pk_rel@entry=0x7f4431f08190,
>     oldslot=oldslot@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@entry=0x7fff7819eb50, tgindx=tgindx@entry=0, 
> finfo=finfo@entry=0x1821a620, instr=instr@entry=0x0,
>     per_tuple_context=per_tuple_context@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@entry=0x180523b0, firing_id=1, 
> estate=estate@entry=0x18218960, delete_ok=delete_ok@entry=false) at 
> trigger.c:4840
> #8  0x000000000070a01b in AfterTriggerEndQuery 
> (estate=estate@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@entry=0x18044070, 
> isTopLevel=isTopLevel@entry=true, 
> setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x184a2ba8,
>     altdest=altdest@entry=0x184a2ba8, qc=qc@entry=0x7fff7819ee90) at 
> pquery.c:1273
> #12 0x000000000092ffb7 in PortalRun (portal=portal@entry=0x18044070, 
> count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, 
> dest=dest@entry=0x184a2ba8,
>     altdest=altdest@entry=0x184a2ba8, qc=qc@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@entry=0x7fff7819f300, 
> startup_data_len=startup_data_len@entry=24,
>     client_sock=client_sock@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@entry=3, 
> argv=argv@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


Reply via email to