Re: tableam scan-API patch broke foreign key validation

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-06 14:34:34 -0400, Tom Lane wrote:
>> These are good questions. Just eyeing RI_FKey_check(), I think
>> that it might not have any significant leaks because most of the work
>> is done in an SPI context, but obviously that's pretty fragile.

> Yea. And especially with potentially needing to free the tuple as above,
> using an explicit context seems more robust to me.

Adjusting the committed test case to process lots of tuples shows that
indeed there is no leak in HEAD. But I concur that using a local context
here would be more future-proof.

BTW, I just stumbled across a different bug in v11 by trying to run
HEAD's test script on it ... not sure if that's a known problem or not:

(gdb) f 3
#3 0x000000000063949c in ExecSetupPartitionTupleRouting (
mtstate=<value optimized out>, rel=0x7f343e4f4170) at execPartition.c:201
201 Assert(update_rri_index == num_update_rri);
(gdb) bt
#0 0x00000037b6232495 in raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00000037b6233c75 in abort () at abort.c:92
#2 0x00000000008a1e6d in ExceptionalCondition (
conditionName=<value optimized out>, errorType=<value optimized out>,
fileName=<value optimized out>, lineNumber=<value optimized out>)
at assert.c:54
#3 0x000000000063949c in ExecSetupPartitionTupleRouting (
mtstate=<value optimized out>, rel=0x7f343e4f4170) at execPartition.c:201
#4 0x00000000006595cb in ExecInitModifyTable (node=0x26a0680,
estate=0x26a1fa8, eflags=16) at nodeModifyTable.c:2343
#5 0x000000000063b179 in ExecInitNode (node=0x26a0680, estate=0x26a1fa8,
eflags=16) at execProcnode.c:174
#6 0x0000000000635824 in InitPlan (queryDesc=<value optimized out>, eflags=16)
at execMain.c:1046
#7 standard_ExecutorStart (queryDesc=<value optimized out>, eflags=16)
at execMain.c:265
#8 0x000000000066c332 in _SPI_pquery (plan=0x269fb38, paramLI=0x26b9048,
snapshot=0x0, crosscheck_snapshot=0x0, read_only=false,
fire_triggers=false, tcount=0) at spi.c:2482
#9 _SPI_execute_plan (plan=0x269fb38, paramLI=0x26b9048, snapshot=0x0,
crosscheck_snapshot=0x0, read_only=false, fire_triggers=false, tcount=0)
at spi.c:2246
#10 0x000000000066c7b6 in SPI_execute_snapshot (plan=0x269fb38,
Values=<value optimized out>, Nulls=<value optimized out>, snapshot=0x0,
crosscheck_snapshot=0x0, read_only=false, fire_triggers=false, tcount=0)
at spi.c:562
#11 0x0000000000838842 in ri_PerformCheck (riinfo=0x268d9c0,
qkey=0x7fff8996f700, qplan=0x269fb38, fk_rel=0x7f343e4f4170,
pk_rel=0x7f343e4f49d0, old_tuple=0x7fff8996fd40, new_tuple=0x0,
detectNewRows=true, expect_OK=9) at ri_triggers.c:2606
#12 0x0000000000839971 in ri_setnull (trigdata=<value optimized out>)
at ri_triggers.c:1400
#13 0x000000000060b0a8 in ExecCallTriggerFunc (trigdata=0x7fff8996fce0,
tgindx=0, finfo=0x26c55e0, instr=0x0, per_tuple_context=0x26aeef0)
at trigger.c:2412
#14 0x000000000060b5e5 in AfterTriggerExecute (events=0x260b8d8, firing_id=1,
estate=0x26c5098, delete_ok=false) at trigger.c:4359
#15 afterTriggerInvokeEvents (events=0x260b8d8, firing_id=1, estate=0x26c5098,
delete_ok=false) at trigger.c:4550
#16 0x000000000060cb82 in AfterTriggerEndQuery (estate=0x26c5098)
at trigger.c:4860
#17 0x0000000000636871 in standard_ExecutorFinish (queryDesc=0x2717b88)
at execMain.c:439
#18 0x0000000000795bf8 in ProcessQuery (plan=<value optimized out>,
sourceText=0x258ef98 "DELETE FROM fk_notpartitioned_pk;", params=0x0,
queryEnv=0x0, dest=<value optimized out>,
completionTag=0x7fff89970030 "DELETE 2") at pquery.c:205
#19 0x0000000000795e35 in PortalRunMulti (portal=0x25f4518, isTopLevel=true,
setHoldSnapshot=false, dest=0x271bb90, altdest=0x271bb90,
completionTag=0x7fff89970030 "DELETE 2") at pquery.c:1286
#20 0x0000000000796610 in PortalRun (portal=0x25f4518,
count=9223372036854775807, isTopLevel=true, run_once=true, dest=0x271bb90,
altdest=0x271bb90, completionTag=0x7fff89970030 "DELETE 2") at pquery.c:799
#21 0x00000000007929dd in exec_simple_query (
query_string=0x258ef98 "DELETE FROM fk_notpartitioned_pk;")
at postgres.c:1145
#22 0x0000000000793f34 in PostgresMain (argc=<value optimized out>,
argv=<value optimized out>, dbname=0x25b8a18 "regression",
username=<value optimized out>) at postgres.c:4182

regards, tom lane