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

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.