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
|
Список | 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 по дате отправления: