Re: ERROR: ORDER/GROUP BY expression not found in targetlist

On 14 June 2016 at 04:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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;"

I see you've committed a fix for this. Thank you.

I thought it would be good to be consistent with the ressortgroupref
handling, and I quite like your fix in that regard.

Do you think it's worth also applying the attached so as to have
ressortgroupref set to NULL more consistently, instead of sometimes
NULL and other times allocated to memory wastefully filled with zeros?

The patch also saved on allocating the array's memory when it's not needed.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services