Re: A test for replay of regression tests

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: A test for replay of regression tests
Дата
Msg-id c184d68a-ef1d-df23-8db5-769f035a43be@dunslane.net
обсуждение исходный текст
Ответ на Re: A test for replay of regression tests  (Andres Freund <andres@anarazel.de>)
Ответы Re: A test for replay of regression tests  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 1/27/22 15:47, Andres Freund wrote:
> Hi,
>
> On 2022-01-27 15:27:17 -0500, Andrew Dunstan wrote:
>> fairywren is not happy with the recovery tests still.
> Any more details?



I'll go back and get some.


>
>
>> I have noticed on a different setup that this test adds 11 minutes to the
>> runtime of the recovery tests, effectively doubling it. The doubling is
>> roughly true on faster setups, too
> Does a normal regress run take roughly that long? Or is the problem that the
> 027_stream_regress.pl ends up defaulting to shared_buffers=1MB, causing lots
> of unnecessary IO?


On crake (slowish fedora 34), a normal check run took 95s, and this test
took 114s. On my windows test instance where I noticed this (w10,
msys2/ucrt), check took 516s and this test took 685s.


>
>
>> . At least I would like a simple
>> way to disable the test.
> One thing we could do to speed up the overall runtime would be to move
> 027_stream_regress.pl to something numbered earlier. Combined with
> PROVE_FLAGS=-j2 that could at least run them in parallel with the rest of the
> recovery tests.
>
>

Seems like a bandaid.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Creation of an empty table is not fsync'd at checkpoint
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: A test for replay of regression tests