From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Weird test mixup |
Date: | 2024-03-15 18:27:27 |
Message-ID: | 2528845.1710527247@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 15/03/2024 16:00, Tom Lane wrote:
>> It may be even worse than it appears from the buildfarm status page.
>> My animals were stuck in infinite loops that required a manual "kill"
>> to get out of, and it's reasonable to assume there are others that
>> will require owner intervention. Why would this test have done that,
>> if the module failed to load?
> The gin_incomplete_split test inserts rows until it hits the injection
> point, at page split. There is a backstop, it should give up after 10000
> iterations, but that was broken. Fixed that, thanks for the report!
Duh ...
> Hmm, don't we have any timeout that would kill tests if they get stuck?
AFAIK, the only constraint on a buildfarm animal's runtime is the
wait_timeout setting, which is infinite by default, and was on my
machines. (Not anymore ;-).) We do have timeouts in (most?) TAP
tests, but this wasn't a TAP test.
If this is a continuous-insertion loop, presumably it will run the
machine out of disk space eventually, which could be unpleasant
if there are other services running besides the buildfarm.
I think I'll go notify the buildfarm owners list to check for
trouble.
Are there limits on the runtime of CI or cfbot jobs? Maybe
somebody should go check those systems.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-03-15 19:11:08 | Re: Weird test mixup |
Previous Message | Amonson, Paul D | 2024-03-15 17:43:39 | RE: Popcount optimization using AVX512 |