Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hCqsg-0005Vg-OX for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Apr 2019 19:21:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hCqse-0008U1-Cc for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Apr 2019 19:21:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hCqse-0008P4-1v for pgsql-hackers@lists.postgresql.org; Sat, 06 Apr 2019 19:21:32 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hCqsa-0002XB-Mq for pgsql-hackers@lists.postgresql.org; Sat, 06 Apr 2019 19:21:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x36JLLAX013345; Sat, 6 Apr 2019 15:21:21 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@lists.postgresql.org, Hadi Moshayedi Subject: Re: tableam scan-API patch broke foreign key validation In-reply-to: <20190406183834.3dvhl24sxicgblaj@alap3.anarazel.de> References: <19030.1554574075@sss.pgh.pa.us> <19246.1554574409@sss.pgh.pa.us> <20190406182258.pvk5zkqdc6dobfg7@alap3.anarazel.de> <19906.1554575674@sss.pgh.pa.us> <20190406183834.3dvhl24sxicgblaj@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Sat, 06 Apr 2019 11:38:34 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13343.1554578481.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 06 Apr 2019 15:21:21 -0400 Message-ID: <13344.1554578481@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund 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=3D, rel=3D0x7f343e4f4170) at execPartitio= n.c:201 201 Assert(update_rri_index =3D=3D num_update_rri); (gdb) bt #0 0x00000037b6232495 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000037b6233c75 in abort () at abort.c:92 #2 0x00000000008a1e6d in ExceptionalCondition ( conditionName=3D, errorType=3D, = fileName=3D, lineNumber=3D) at assert.c:54 #3 0x000000000063949c in ExecSetupPartitionTupleRouting ( mtstate=3D, rel=3D0x7f343e4f4170) at execPartitio= n.c:201 #4 0x00000000006595cb in ExecInitModifyTable (node=3D0x26a0680, = estate=3D0x26a1fa8, eflags=3D16) at nodeModifyTable.c:2343 #5 0x000000000063b179 in ExecInitNode (node=3D0x26a0680, estate=3D0x26a1f= a8, = eflags=3D16) at execProcnode.c:174 #6 0x0000000000635824 in InitPlan (queryDesc=3D, efl= ags=3D16) at execMain.c:1046 #7 standard_ExecutorStart (queryDesc=3D, eflags=3D16= ) at execMain.c:265 #8 0x000000000066c332 in _SPI_pquery (plan=3D0x269fb38, paramLI=3D0x26b90= 48, = snapshot=3D0x0, crosscheck_snapshot=3D0x0, read_only=3Dfalse, = fire_triggers=3Dfalse, tcount=3D0) at spi.c:2482 #9 _SPI_execute_plan (plan=3D0x269fb38, paramLI=3D0x26b9048, snapshot=3D0= x0, = crosscheck_snapshot=3D0x0, read_only=3Dfalse, fire_triggers=3Dfalse, t= count=3D0) at spi.c:2246 #10 0x000000000066c7b6 in SPI_execute_snapshot (plan=3D0x269fb38, = Values=3D, Nulls=3D, snapsho= t=3D0x0, = crosscheck_snapshot=3D0x0, read_only=3Dfalse, fire_triggers=3Dfalse, t= count=3D0) at spi.c:562 #11 0x0000000000838842 in ri_PerformCheck (riinfo=3D0x268d9c0, = qkey=3D0x7fff8996f700, qplan=3D0x269fb38, fk_rel=3D0x7f343e4f4170, = pk_rel=3D0x7f343e4f49d0, old_tuple=3D0x7fff8996fd40, new_tuple=3D0x0, = detectNewRows=3Dtrue, expect_OK=3D9) at ri_triggers.c:2606 #12 0x0000000000839971 in ri_setnull (trigdata=3D) at ri_triggers.c:1400 #13 0x000000000060b0a8 in ExecCallTriggerFunc (trigdata=3D0x7fff8996fce0, = tgindx=3D0, finfo=3D0x26c55e0, instr=3D0x0, per_tuple_context=3D0x26ae= ef0) at trigger.c:2412 #14 0x000000000060b5e5 in AfterTriggerExecute (events=3D0x260b8d8, firing_= id=3D1, = estate=3D0x26c5098, delete_ok=3Dfalse) at trigger.c:4359 #15 afterTriggerInvokeEvents (events=3D0x260b8d8, firing_id=3D1, estate=3D= 0x26c5098, = delete_ok=3Dfalse) at trigger.c:4550 #16 0x000000000060cb82 in AfterTriggerEndQuery (estate=3D0x26c5098) at trigger.c:4860 #17 0x0000000000636871 in standard_ExecutorFinish (queryDesc=3D0x2717b88) at execMain.c:439 #18 0x0000000000795bf8 in ProcessQuery (plan=3D, = sourceText=3D0x258ef98 "DELETE FROM fk_notpartitioned_pk;", params=3D0= x0, = queryEnv=3D0x0, dest=3D, = completionTag=3D0x7fff89970030 "DELETE 2") at pquery.c:205 #19 0x0000000000795e35 in PortalRunMulti (portal=3D0x25f4518, isTopLevel=3D= true, = setHoldSnapshot=3Dfalse, dest=3D0x271bb90, altdest=3D0x271bb90, = completionTag=3D0x7fff89970030 "DELETE 2") at pquery.c:1286 #20 0x0000000000796610 in PortalRun (portal=3D0x25f4518, = count=3D9223372036854775807, isTopLevel=3Dtrue, run_once=3Dtrue, dest=3D= 0x271bb90, = altdest=3D0x271bb90, completionTag=3D0x7fff89970030 "DELETE 2") at pqu= ery.c:799 #21 0x00000000007929dd in exec_simple_query ( query_string=3D0x258ef98 "DELETE FROM fk_notpartitioned_pk;") at postgres.c:1145 #22 0x0000000000793f34 in PostgresMain (argc=3D, = argv=3D, dbname=3D0x25b8a18 "regression", = username=3D) at postgres.c:4182 regards, tom lane