On Thu, Aug 17, 2017 at 7:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
