Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90 - Mailing list pgsql-hackers

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.17rows=16 width=72)              Workers Planned: 4              ->  Partial GroupAggregate
(cost=524.10..542.89rows=4 width=72)                    Group Key: tenk1.string4                    ->  Sort
(cost=524.10..530.35rows=2500 width=68)                          Sort Key: tenk1.string4                          ->
ParallelSeq 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')
atexecMain.c:362 

        regards, tom lane