On Fri, Mar 2, 2018 at 2:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
/me blinks. So you're not upset about the thing that actually caused the failure, which looks very likely to be a bug in the commits I pushed today, but are instead upset about something that didn't cause a failure but which is shiny and nearby? Unless this is causing actual failures I don't think we should change it. It would be very sad if we started routinely getting Workers Launched < Workers Planned due to some newly-introduced bug and had no idea it was happening because we'd hidden it to avoid imaginary buildfarm failures. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company