Re: Grouping isolationtester tests in the schedule

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Grouping isolationtester tests in the schedule
Date: 2019-08-07 16:52:48
Message-ID: 5613.1565196768@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> The elephant in the room is the 'timeouts' test, which takes about 40
> seconds, out of a total runtime of 90 seconds. So we'd really want to
> run that in parallel with everything else. Or split 'timeouts' into
> multiple tests that could run in parallel. I don't think grouping the
> rest of the tests differently will make much difference to how easy or
> hard that is.

The problem in "timeouts" is that it has to use drearily long timeouts
to be sure that the behavior will be stable even on really slow machines
(think CLOBBER_CACHE_ALWAYS or valgrind --- it can take seconds for them
to reach a waiting state that other machines reach quickly). If we run
such tests in parallel with anything else, that risks re-introducing the
instability. I'm not very sure what we can do about that. But you might
be right that unless we can solve that, there's not going to be much to be
gained from parallelizing the rest.

I wonder if there's some way to scale the timeout values based on
machine speed? But how would the test get that info?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-08-07 16:55:59 Re: no default hash partition
Previous Message Tom Lane 2019-08-07 16:44:13 Re: no default hash partition