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 |
Message-ID: | C5105396-9938-4CEE-8711-94481F311102@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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.
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 |