Parallel append plan instability/randomness

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