Re: ERROR: ORDER/GROUP BY expression not found in targetlist - Mailing list pgsql-hackers

From David Rowley
Subject Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Date
Msg-id CAKJS1f9Qqv86hQZpF4tiP-mFqgR2LP8ezOfNuboJvkgZNXzhog@mail.gmail.com
Whole thread Raw
In response to Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 14 June 2016 at 04:07, Tom Lane <tgl@sss.pgh.pa.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

Attachment

pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: Prepared statements and generic plans
Next
From: Aleksey Demakov
Date:
Subject: Using FDW AddForeignUpdateTargets for a hidden pseudo-column