[HACKERS] Cost of src/test/recovery and .../subscription tests

Поиск
Список
Период
Сортировка
От Tom Lane
Тема [HACKERS] Cost of src/test/recovery and .../subscription tests
Дата
Msg-id 21358.1492622881@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] Cost of src/test/recovery and .../subscription tests  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: [HACKERS] Cost of src/test/recovery and .../subscription tests  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
So I updated longfin to the new release of the buildfarm client,
and was quite dismayed by the fact that its cycle time went
from 16 minutes to 24.  Some of that might be random effects like
the state of the kernel disk caches, but a large chunk of it
--- over 5 minutes --- evidently is from src/test/recovery/,
which the buildfarm script didn't run before and now does.

I am going to say flat out that that's unacceptably long for
a test script that will be run dozens of times a day by the
buildfarm.  There isn't any other test script that takes more
than circa 90 seconds on that machine, and I don't think this
one should either.

I'm a bit dubious about whether src/test/subscription is being
reasonably thrifty of test time either.  Do we really need twice
the runtime of the entire core regression suite to test that?

There was already a good argument not to enable the TAP tests
on slower buildfarm animals, and if nothing is done about these
additions, I'm afraid that such testing will be put permanently
out of reach.  I don't even want to think about how long it
might take a CLOBBER_CACHE_ALWAYS animal to run these tests.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Douglas Doole
Дата:
Сообщение: Re: [HACKERS] [PATCH] Push limit to sort through a subquery
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19