Re: A test for replay of regression tests

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


On February 1, 2022 6:11:24 PM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>> It looks like it's processing statements fairly consistently slowly
>> through the whole period. Each non-trivial statement takes a bit
>> under ~10ms, so it would make sense if by the time we've processed
>> ~2.5k lines we've clocked up 30 seconds and a VACUUM replay whacks us.
>This test is set up to time out after 30 seconds? We've long had
>an unofficial baseline that no timeouts under 180 seconds should
>be used in the buildfarm.

30s is the default value of the streaming replay conflict timeout. After that the startup process cancelled the session running pg_dump. So it's not an intentional timeout in the test.

It's not surprising that pg_dump takes 30s on that old a machine. But more than 2min still surprised me. Is that really do be expected?

- Andres
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-02 02:33:10 Re: A test for replay of regression tests
Previous Message Tom Lane 2022-02-02 02:11:24 Re: A test for replay of regression tests