Re: Testing "workers launched" in expected output? Really? - Mailing list pgsql-hackers

On Fri, Mar 2, 2018 at 2:28 PM, Tom Lane <tgl@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