So buildfarm member piculet just fell over like this: ================== pgsql.build/src/test/regress/regression.diffs ================== *** /home/andres/build/buildfarm-piculet/HEAD/pgsql.build/../pgsql/src/test/regress/expected/select_parallel.out 2018-02-28 16:10:01.986941733 +0000 --- /home/andres/build/buildfarm-piculet/HEAD/pgsql.build/src/test/regress/results/select_parallel.out 2018-03-02 19:13:57.843939790 +0000 *************** *** 485,495 **** QUERY PLAN -------------------------------------------------------------------------- Aggregate (actual rows=1 loops=1) ! -> Nested Loop (actual rows=98000 loops=1) -> Seq Scan on tenk2 (actual rows=10 loops=1) Filter: (thousand = 0) Rows Removed by Filter: 9990 ! -> Gather (actual rows=9800 loops=10) Workers Planned: 4 Workers Launched: 4 -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50) --- 485,495 ---- QUERY PLAN -------------------------------------------------------------------------- Aggregate (actual rows=1 loops=1) ! -> Nested Loop (actual rows=97836 loops=1) -> Seq Scan on tenk2 (actual rows=10 loops=1) Filter: (thousand = 0) Rows Removed by Filter: 9990 ! -> Gather (actual rows=9784 loops=10) Workers Planned: 4 Workers Launched: 4 -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50)
====================================================================== and now I am on the warpath. I have no idea whether or not the diff here is significant --- maybe it is --- but I am desperately unhappy that we have expected-output files that will fail if fewer than the expected number of workers launched. I find that absolutely unacceptable. It reminds me entirely too much of when I had to package MySQL for Red Hat, and half the time the package builds failed in Red Hat's buildfarm, because their tests weren't robust about passing on heavily loaded machines. I won't stand for our tests becoming like that. Perhaps we could deal with this by suppressing the Workers Planned/ Launched lines when we are suppressing costs? regards, tom lane