Re: parallel.c is not marked as test covered

On Wed, May 11, 2016 at 1:38 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I would just go fix this, along the lines of
>>
>> *************** create_plain_partial_paths(PlannerInfo *
>> *** 702,708 ****
>> * with all of its inheritance siblings it may well pay off.
>> */
>> if (rel->pages < parallel_threshold &&
>> ! rel->reloptkind == RELOPT_BASEREL)
>> return;
>>
>> /*
>> --- 703,710 ----
>> * with all of its inheritance siblings it may well pay off.
>> */
>> if (rel->pages < parallel_threshold &&
>> ! rel->reloptkind == RELOPT_BASEREL &&
>> ! force_parallel_mode == FORCE_PARALLEL_OFF)
>> return;
>>
>> /*
>>
>> except that doing so and running the regression tests with
>> force_parallel_mode = on results in core dumps.
>
> Nonetheless, that is a bug. (I only get one crash - do you get more?)

This looks like a bug in the parallel aggregate code.

#0 make_partialgroup_input_target (root=0x7faa5f002d20,
final_target=0x7faa5f004270) at planner.c:4308
4308 Index sgref = final_target->sortgrouprefs[i];
(gdb) p debug_query_string
$1 = 0x7faa5d00b638 "SELECT SUM(COUNT(f1)) OVER () FROM int4_tbl WHERE f1=42;"
Current language: auto; currently minimal
(gdb) bt
#0 make_partialgroup_input_target (root=0x7faa5f002d20,
final_target=0x7faa5f004270) at planner.c:4308
#1 0x0000000101df4889 in create_grouping_paths (root=0x7faa5f002d20,
input_rel=0x7faa5f0034b0, target=0x7faa5f004270, rollup_lists=0x0,
rollup_groupclauses=0x0) at planner.c:3421
#2 0x0000000101df19a0 in grouping_planner (root=0x7faa5f002d20,
inheritance_update=0 '\0', tuple_fraction=0) at planner.c:1796
#3 0x0000000101def276 in subquery_planner (glob=0x7faa5f002b90,
parse=0x7faa5d00cb80, parent_root=0x0, hasRecursion=0 '\0',
tuple_fraction=0) at planner.c:758
#4 0x0000000101dee2de in standard_planner (parse=0x7faa5d00cb80,
cursorOptions=256, boundParams=0x0) at planner.c:307
#5 0x0000000101dedf81 in planner (parse=0x7faa5d00cb80,
cursorOptions=256, boundParams=0x0) at planner.c:177
#6 0x0000000101eed7b6 in pg_plan_query (querytree=0x7faa5d00cb80,
cursorOptions=256, boundParams=0x0) at postgres.c:798
#7 0x0000000101eed8a3 in pg_plan_queries (querytrees=0x7faa5f002cc0,
cursorOptions=256, boundParams=0x0) at postgres.c:857
#8 0x0000000101ef05ad in exec_simple_query
(query_string=0x7faa5d00b638 "SELECT SUM(COUNT(f1)) OVER () FROM
int4_tbl WHERE f1=42;") at postgres.c:1022
#9 0x0000000101eefa8f in PostgresMain (argc=1, argv=0x7faa5b005be0,
dbname=0x7faa5b005940 "regression", username=0x7faa5b005920 "rhaas")
at postgres.c:4059
#10 0x0000000101e45209 in BackendRun (port=0x7faa5ae01770) at postmaster.c:4258
#11 0x0000000101e44449 in BackendStartup (port=0x7faa5ae01770) at
postmaster.c:3932
#12 0x0000000101e433ef in ServerLoop () at postmaster.c:1690
#13 0x0000000101e40a23 in PostmasterMain (argc=8, argv=0x7faa5ac099b0)
at postmaster.c:1298
#14 0x0000000101d6e160 in main (argc=8, argv=0x7faa5ac099b0) at main.c:228
(gdb) p final_target->sortgrouprefs
$2 = (Index *) 0x0

I don't immediately understand what's going wrong here. It looks to
me like make_group_input_target() already called, and that worked OK,
but now make_partialgroup_input_target() is failing using more-or-less
the same logic. Presumably that's because make_group_input_target()
was called on final_target as returned by create_pathtarget(root,
tlist), but make_partialgroup_input_target() is being called on
grouping_target, which I'm guessing came from
make_window_input_target, which somehow lacks sortgroupref labeling.
But I don't immediately see how that would happen, so there's
obviously something I'm missing here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company