Re: Maybe BF "timedout" failures are the client script's fault?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Banck <mbanck@gmx.net>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2026-01-09T21:42:22Z
Lists: pgsql-hackers
Michael Banck <mbanck@gmx.net> writes: > On Fri, Jan 09, 2026 at 03:41:03PM -0500, Tom Lane wrote: >> Looking into the buildfarm client, I realized that it's assuming that >> "sleep($wait_time)" is sufficient to wait for $wait_time seconds. >> However, the Perl docs point out that sleep() can be interrupted by a >> signal. So now I'm suspicious that many of these failures are caused >> by a stray signal waking up the wait_timeout thread prematurely. > That might be the case for those other failures, but unfortunately, I > think the fruitcrow failures are really because it gets stuck endlessly > in the test_shm_mq test (it is always that one) and only the test > timeout kicks it out. If it's always the same test, then yeah that's evidence against my theory (at least for fruitcrow's failures). > I've ran that test manually quite a lot and either it finishes in 10-15 > seconds, or (presumably) never. This is not really easy to see in the > public builfarm logs (at least I can't find it on a quick glance), but > I've routinely checked the log timestamps of the runs, and they really > take one hour (wait_timeout) in the case of a hang. Hmm. Then why is the BF report showing that the total runtime is nowhere near that? I wonder how those times are gathered ... regards, tom lane