On 9 April 2018 at 09:54, Tom Lane <t...@sss.pgh.pa.us> wrote: > BTW, pademelon just exhibited a different instability in this test: > > *** > /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/expected/partition_prune.out > Sun Apr 8 01:56:04 2018 > --- > /home/bfarm/bf-data/HEAD/pgsql.build/src/test/regress/results/partition_prune.out > Sun Apr 8 17:48:14 2018 > *************** > *** 1606,1612 **** > -> Partial Aggregate (actual rows=1 loops=3) > -> Parallel Append (actual rows=0 loops=3) > Subplans Removed: 6 > ! -> Parallel Seq Scan on ab_a2_b1 (actual rows=0 > loops=1) > Filter: ((a >= $1) AND (a <= $2) AND (b < 4)) > -> Parallel Seq Scan on ab_a2_b2 (actual rows=0 > loops=1) > Filter: ((a >= $1) AND (a <= $2) AND (b < 4)) > --- 1606,1612 ---- > -> Partial Aggregate (actual rows=1 loops=3) > -> Parallel Append (actual rows=0 loops=3) > Subplans Removed: 6 > ! -> Parallel Seq Scan on ab_a2_b1 (actual rows=0 > loops=2) > Filter: ((a >= $1) AND (a <= $2) AND (b < 4)) > -> Parallel Seq Scan on ab_a2_b2 (actual rows=0 > loops=1) > Filter: ((a >= $1) AND (a <= $2) AND (b < 4)) >
Reading code it looks like a bug in choose_next_subplan_for_worker(): The following needs to be changed for this patch: /* Advance to next plan. */ pstate->pa_next_plan++; I'll think a bit harder about the best way to fix and submit a patch for it later. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
