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

On Thu, Aug 17, 2017 at 7:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.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