On Wed, May 11, 2016 at 1:38 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
