On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I wrote: > > Amit Kapila <amit.kapila@enterprisedb.com> writes: > >> It is slightly tricky to write a reproducible parallel-query test, but > >> point taken and I think we should try to have a test unless such a test is > >> really time consuming. > > > BTW, decent regression tests could be written without the need to create > > enormous tables if the minimum rel size in create_plain_partial_paths() > > could be configured to something less than 1000 blocks. I think it's > > fairly crazy that that arbitrary constant is hard-wired anyway. Should > > we make it a GUC? > > Just as an experiment to see what would happen, I did > > - int parallel_threshold = 1000; > + int parallel_threshold = 1; > > and ran the regression tests. I got a core dump in the window.sql test: > > Program terminated with signal 11, Segmentation fault. > #0 0x0000000000664dbc in make_partialgroup_input_target (root=0x1795018, > input_rel=0x17957a8, target=0x17bf228, rollup_lists=0x0, > rollup_groupclauses=0x0) at planner.c:4307 > 4307 Index sgref = final_target->sortgrouprefs[i]; > (gdb) bt > #0 0x0000000000664dbc in make_partialgroup_input_target (root=0x1795018, > input_rel=0x17957a8, target=0x17bf228, rollup_lists=0x0, > rollup_groupclauses=0x0) at planner.c:4307 > #1 create_grouping_paths (root=0x1795018, input_rel=0x17957a8, > target=0x17bf228, rollup_lists=0x0, rollup_groupclauses=0x0) > at planner.c:3420 > #2 0x0000000000667405 in grouping_planner (root=0x1795018, > inheritance_update=0 '\000', tuple_fraction=0) at planner.c:1794 > #3 0x0000000000668c80 in subquery_planner (glob=<value optimized out>, > parse=0x1703580, parent_root=<value optimized out>, > hasRecursion=<value optimized out>, tuple_fraction=0) at planner.c:769 > #4 0x0000000000668ea5 in standard_planner (parse=0x1703580, > cursorOptions=256, boundParams=0x0) at planner.c:308 > #5 0x00000000006691b6 in planner (parse=<value optimized out>, > cursorOptions=<value optimized out>, boundParams=<value optimized out>) > at planner.c:178 > #6 0x00000000006fb069 in pg_plan_query (querytree=0x1703580, > cursorOptions=256, boundParams=0x0) at postgres.c:798 > (gdb) p debug_query_string > $1 = 0x1702078 "SELECT SUM(COUNT(f1)) OVER () FROM int4_tbl WHERE f1=42;" > > which I think may be another manifestation of the failure-to-apply-proper- > pathtarget issue we're looking at in this thread. Or maybe it's just > an unjustified assumption in make_partialgroup_input_target that the > input path must always have some sortgrouprefs assigned. >
I don't see this problem after your recent commit - 89d53515e53ea080029894939118365b647489b3. Are you still getting it?
> > Before getting to that point, there was also an unexplainable plan change: >
Yeah, I am also seeing such a plan change, but I this is a separate thing to investigate.
