From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Adam, Etienne (Nokia-TECH/Issy Les Moulineaux) <etienne.adam@nokia.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Cc: Duquesne, Pierre (Nokia-TECH/Issy Les Moulineaux) <pierre.duquesne@nokia.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90
Date: Thu, 17 Aug 2017 10:19:24 -0400
Message-ID: <2941.1502979564@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
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:
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, amit.kapila16@gmail.com, robertmhaas@gmail.com, noah@leadboat.com, etienne.adam@nokia.com, pierre.duquesne@nokia.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90
In-Reply-To: <2941.1502979564@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox