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

On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I wrote:
> > Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com