Re: tableam scan-API patch broke foreign key validation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tableam scan-API patch broke foreign key validation
Дата
Msg-id 13344.1554578481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: tableam scan-API patch broke foreign key validation  (Andres Freund <andres@anarazel.de>)
Ответы Re: tableam scan-API patch broke foreign key validation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@anarazel.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tableam scan-API patch broke foreign key validation
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: ToDo: show size of partitioned table