Amit Langote <langote_amit...@lab.ntt.co.jp> writes:
> On 2017/06/12 11:09, Joe Conway wrote:
>> On 06/11/2017 05:35 PM, Tom Lane wrote:
>>> First guess is that map_partition_varattnos has forgotten to handle
>>> WithCheckOption.qual.
>> Drat. I'll take a look, but it would probably be good if someone
>> generally familiar with the partitioned tables patches have a look as well.
> I am looking too. Commit 587cda35ca3 which added that code did add a test
> in updatable_views.sql, but tests added by this commit have perhaps
> exposed something not previously covered.
My first guess above is wrong -- the undefined reference is actually
"mtstate->mt_plans[i]". This is because mtstate->mt_num_partitions is
more than mtstate->mt_nplans in the failing case, so that the blithe
assumption that we can use the partition number to index into
mtstate->mt_plans is certainly wrong. Don't know how this should
be corrected, offhand, but do we really have more than one plan
for a partitioned query?
The specific query that's failing is
(gdb) p debug_query_string
$1 = 0x11b6220 "INSERT INTO part_document VALUES (100, 11, 5,
'regress_rls_dave', 'testing pp1');"
and you can get a crash without all the valgrind effort by adding
diff --git a/src/backend/executor/nodeModifyTable.c
b/src/backend/executor/nodeModifyTable.c
index bf26488..5013a6d 100644
*** a/src/backend/executor/nodeModifyTable.c
--- b/src/backend/executor/nodeModifyTable.c
*************** ExecInitModifyTable(ModifyTable *node, E
*** 1844,1849 ****
--- 1844,1850 ----
Assert(operation == CMD_INSERT);
resultRelInfo = mtstate->mt_partitions;
+ Assert(mtstate->mt_num_partitions == mtstate->mt_nplans);
wcoList = linitial(node->withCheckOptionLists);
for (i = 0; i < mtstate->mt_num_partitions; i++)
{
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
