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

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:

Program terminated with signal 11, Segmentation fault.
#0 0x000000000064b4e4 in swap_nodes (heap=0x15a9440) at binaryheap.c:223
223 heap->bh_nodes[a] = heap->bh_nodes[b];
(gdb) bt
#0 0x000000000064b4e4 in swap_nodes (heap=0x15a9440) at binaryheap.c:223
#1 binaryheap_remove_first (heap=0x15a9440) at binaryheap.c:189
#2 0x0000000000634196 in gather_merge_getnext (pstate=<value optimized out>)
at nodeGatherMerge.c:479
#3 ExecGatherMerge (pstate=<value optimized out>) at nodeGatherMerge.c:241
#4 0x00000000006251fe in ExecProcNode (aggstate=0x157a6d0)
at ../../../src/include/executor/executor.h:249
#5 fetch_input_tuple (aggstate=0x157a6d0) at nodeAgg.c:688
#6 0x0000000000629264 in agg_retrieve_direct (pstate=<value optimized out>)
at nodeAgg.c:2313
#7 ExecAgg (pstate=<value optimized out>) at nodeAgg.c:2124
#8 0x00000000006396ef in ExecProcNode (pstate=0x1579d98)
at ../../../src/include/executor/executor.h:249
#9 ExecNestLoop (pstate=0x1579d98) at nodeNestloop.c:160
#10 0x000000000061bc3f in ExecProcNode (queryDesc=0x14d5570,
direction=<value optimized out>, count=0, execute_once=-104 '\230')
at ../../../src/include/executor/executor.h:249
#11 ExecutePlan (queryDesc=0x14d5570, direction=<value optimized out>,
count=0, execute_once=-104 '\230') at execMain.c:1693
#12 standard_ExecutorRun (queryDesc=0x14d5570,
direction=<value optimized out>, count=0, execute_once=-104 '\230')
at execMain.c:362

regards, tom lane