Re: A test for replay of regression tests

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A test for replay of regression tests
Date: 2022-01-27 22:16:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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
> 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
> 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.



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-01-27 22:21:58 Re: A test for replay of regression tests
Previous Message Thomas Munro 2022-01-27 22:11:28 Re: Creation of an empty table is not fsync'd at checkpoint