From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test |
Date: | 2024-07-25 12:12:38 |
Message-ID: | d7d2996e-0ca2-4887-b022-75bf124de40a@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-07-25 Th 8:00 AM, Alexander Lakhin wrote:
> Hello hackers,
>
> Please take a look at today's failure [1], that raises several questions
> at once:
> 117/244 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
> TIMEOUT 3001.48s exit status 1
> 180/244 postgresql:pg_amcheck / pg_amcheck/005_opclass_damage
> TIMEOUT 3001.43s exit status 1
>
> Ok: 227
> Expected Fail: 0
> Fail: 0
> Unexpected Pass: 0
> Skipped: 15
> Timeout: 2
>
> But looking at the previous test run [2], marked 'OK', I can see almost
> the same:
> 115/244 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
> TIMEOUT 3001.54s exit status 1
> 176/244 postgresql:pg_amcheck / pg_amcheck/005_opclass_damage
> TIMEOUT 3001.26s exit status 1
>
> Ok: 227
> Expected Fail: 0
> Fail: 0
> Unexpected Pass: 0
> Skipped: 15
> Timeout: 2
>
> So it's not clear to me, why is the latter test run considered failed
> unlike the former?
Yesterday I changed the way we detect failure in the buildfarm client,
and pushed that to fairywren (and a few more of my animals). Previously
it did not consider a timeout to be a failure, but now it does. I'm
going to release that soon.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2024-07-25 12:18:47 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Alexander Lakhin | 2024-07-25 12:00:00 | fairywren timeout failures on the pg_amcheck/005_opclass_damage test |