Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90

On Thu, Aug 17, 2017 at 7:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I should think it wouldn't be that expensive to create a test
>>> case, if you already have test cases that invoke GatherMerge.
>>> Adding a right join against a VALUES clause with a small number of
>>> entries, and a non-mergeable/hashable join clause, ought to do it.
>
>> I have done some experiments based on this idea to generate a test,
>> but I think it is not as straightforward as it appears.
>
> I did this (the first 4 SETs duplicate what's already used in
> select_parallel.sql):
>
> regression=# set parallel_setup_cost=0;
> SET
> regression=# set parallel_tuple_cost=0;
> SET
> regression=# set min_parallel_table_scan_size=0;
> SET
> regression=# set max_parallel_workers_per_gather=4;
> SET
> regression=# set enable_hashagg TO 0;
> SET
> regression=# set enable_material TO 0;
> SET
> regression=# explain select * from (select string4, count((unique2))
> from tenk1 group by string4 order by string4) ss right join
> (values(1),(2)) v(x) on true;
> QUERY PLAN
> --------------------------------------------------------------------------------------------------
> Nested Loop Left Join (cost=524.15..1086.77 rows=8 width=76)
> -> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4)
> -> Finalize GroupAggregate (cost=524.15..543.29 rows=4 width=72)
> Group Key: tenk1.string4
> -> Gather Merge (cost=524.15..543.17 rows=16 width=72)
> Workers Planned: 4
> -> Partial GroupAggregate (cost=524.10..542.89 rows=4 width=72)
> Group Key: tenk1.string4
> -> Sort (cost=524.10..530.35 rows=2500 width=68)
> Sort Key: tenk1.string4
> -> Parallel Seq Scan on tenk1 (cost=0.00..383.00 rows=2500 width=68)
> (11 rows)
>
> regression=# select * from (select string4, count((unique2))
> from tenk1 group by string4 order by string4) ss right join
> (values(1),(2)) v(x) on true;
> server closed the connection unexpectedly
>
>
> So, not only is it not that hard to reach ExecReScanGatherMerge,
> but there is indeed a bug to fix there somewhere. The stack
> trace indicates that the failure occurs in a later execution
> of ExecGatherMerge:
>

This will be fixed by the patch [1] (execrescan_gathermerge_v2.patch)
I posted sometime back. The test case is slightly different, but may
I can re post the patch with your test case.

[1] - https://www.postgresql.org/message-id/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ%40mail.gmail.com

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