According to buildfarm member silverfish,
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=silverfish&dt=2018-01-06%2008%3A53%3A38
it's possible to sometimes get this failure in the regression tests:
***
/mnt/buildfarm/buildroot/HEAD/pgsql.build/../pgsql/src/test/regress/expected/select_parallel.out
Tue Dec 19 20:24:02 2017
---
/mnt/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/results/select_parallel.out
Sat Jan 6 09:21:39 2018
***************
*** 75,84 ****
Workers Planned: 3
-> Partial Aggregate
-> Parallel Append
-> Seq Scan on d_star
-> Seq Scan on f_star
-> Seq Scan on e_star
- -> Seq Scan on b_star
-> Seq Scan on c_star
-> Seq Scan on a_star
(11 rows)
--- 75,84 ----
Workers Planned: 3
-> Partial Aggregate
-> Parallel Append
+ -> Seq Scan on b_star
-> Seq Scan on d_star
-> Seq Scan on f_star
-> Seq Scan on e_star
-> Seq Scan on c_star
-> Seq Scan on a_star
(11 rows)
Irreproducible failures in the regression tests are not very acceptable.
Furthermore, considering that the query being tested is
explain (costs off)
select round(avg(aa)), sum(aa) from a_star;
it seems to me that the "expected" order of the sub-scans is mighty
random to begin with. A non-parallel implementation of the same
query will consistently scan these tables in their inheritance order:
Aggregate
-> Append
-> Seq Scan on a_star
-> Seq Scan on b_star
-> Seq Scan on c_star
-> Seq Scan on d_star
-> Seq Scan on e_star
-> Seq Scan on f_star
Could we fix the parallel case to behave similarly please?
regards, tom lane
