From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>,
        "Adam,
 Etienne (Nokia-TECH/Issy Les Moulineaux)" <etienne.adam@nokia.com>,
        PostgreSQL Bugs <pgsql-bugs@postgresql.org>,
        "Duquesne,
 Pierre (Nokia-TECH/Issy Les Moulineaux)" <pierre.duquesne@nokia.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90
In-reply-to: 
 <CAA4eK1J_dRv+pGt2bquwmwd_K9+Nght2=tbAc3uUzCinJTMmLg@mail.gmail.com>
References: 
 <CAL7LBcYM-32B=n_-h_wPHWiML26UvqP3b_WxD7MgXgOwmxvTFw@mail.gmail.com>
 <11673.1502467154@sss.pgh.pa.us> <20170815025243.GA3986579@rfd.leadboat.com>
 <CAA4eK1KeQWZOoDmDmGMwuqzPW9JhRS+ditQVFdAfGjNmMZzqMQ@mail.gmail.com>
 <CA+TgmoaWPtfdcZjg+dqLephgKaG7kF8DEdvB870A2t4cUh5x+Q@mail.gmail.com>
 <26053.1502804769@sss.pgh.pa.us>
 <CAA4eK1J_dRv+pGt2bquwmwd_K9+Nght2=tbAc3uUzCinJTMmLg@mail.gmail.com>
Comments: In-reply-to Amit Kapila <amit.kapila16@gmail.com>
	message dated "Thu, 17 Aug 2017 10:07:42 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2940.1502979564.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Aug 2017 10:19:24 -0400
Message-ID: <2941.1502979564@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

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=3D# set parallel_setup_cost=3D0;
SET
regression=3D# set parallel_tuple_cost=3D0;
SET
regression=3D# set min_parallel_table_scan_size=3D0;
SET
regression=3D# set max_parallel_workers_per_gather=3D4;
SET
regression=3D# set enable_hashagg TO 0;
SET
regression=3D# set enable_material TO 0;
SET
regression=3D# 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=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20
---------------------------------------------------------------------------=
-----------------------
 Nested Loop Left Join  (cost=3D524.15..1086.77 rows=3D8 width=3D76)
   ->  Values Scan on "*VALUES*"  (cost=3D0.00..0.03 rows=3D2 width=3D4)
   ->  Finalize GroupAggregate  (cost=3D524.15..543.29 rows=3D4 width=3D72)
         Group Key: tenk1.string4
         ->  Gather Merge  (cost=3D524.15..543.17 rows=3D16 width=3D72)
               Workers Planned: 4
               ->  Partial GroupAggregate  (cost=3D524.10..542.89 rows=3D4 =
width=3D72)
                     Group Key: tenk1.string4
                     ->  Sort  (cost=3D524.10..530.35 rows=3D2500 width=3D6=
8)
                           Sort Key: tenk1.string4
                           ->  Parallel Seq Scan on tenk1  (cost=3D0.00..38=
3.00 rows=3D2500 width=3D68)
(11 rows)

regression=3D# 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=3D0x15a9440) at binaryheap.c:223
223             heap->bh_nodes[a] =3D heap->bh_nodes[b];
(gdb) bt
#0  0x000000000064b4e4 in swap_nodes (heap=3D0x15a9440) at binaryheap.c:223
#1  binaryheap_remove_first (heap=3D0x15a9440) at binaryheap.c:189
#2  0x0000000000634196 in gather_merge_getnext (pstate=3D<value optimized o=
ut>)
    at nodeGatherMerge.c:479
#3  ExecGatherMerge (pstate=3D<value optimized out>) at nodeGatherMerge.c:2=
41
#4  0x00000000006251fe in ExecProcNode (aggstate=3D0x157a6d0)
    at ../../../src/include/executor/executor.h:249
#5  fetch_input_tuple (aggstate=3D0x157a6d0) at nodeAgg.c:688
#6  0x0000000000629264 in agg_retrieve_direct (pstate=3D<value optimized ou=
t>)
    at nodeAgg.c:2313
#7  ExecAgg (pstate=3D<value optimized out>) at nodeAgg.c:2124
#8  0x00000000006396ef in ExecProcNode (pstate=3D0x1579d98)
    at ../../../src/include/executor/executor.h:249
#9  ExecNestLoop (pstate=3D0x1579d98) at nodeNestloop.c:160
#10 0x000000000061bc3f in ExecProcNode (queryDesc=3D0x14d5570,=20
    direction=3D<value optimized out>, count=3D0, execute_once=3D-104 '\230=
')
    at ../../../src/include/executor/executor.h:249
#11 ExecutePlan (queryDesc=3D0x14d5570, direction=3D<value optimized out>,=
=20
    count=3D0, execute_once=3D-104 '\230') at execMain.c:1693
#12 standard_ExecutorRun (queryDesc=3D0x14d5570,=20
    direction=3D<value optimized out>, count=3D0, execute_once=3D-104 '\230=
')
    at execMain.c:362


			regards, tom lane


--=20
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs