Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1veKFc-00BuYE-2j for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 21:42:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1veKFb-008jLO-2Z for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 21:42:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1veKFb-008jLE-1d for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 21:42:32 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1veKFa-0058QS-2l for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 21:42:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 609LgMPo2430116; Fri, 9 Jan 2026 16:42:22 -0500 From: Tom Lane To: Michael Banck cc: Andrew Dunstan , pgsql-hackers@lists.postgresql.org Subject: Re: Maybe BF "timedout" failures are the client script's fault? In-reply-to: <20260109213255.GB21237@p46.dedyn.io;lightning.p46.dedyn.io> References: <2423164.1767991263@sss.pgh.pa.us> <20260109213255.GB21237@p46.dedyn.io;lightning.p46.dedyn.io> Comments: In-reply-to Michael Banck message dated "Fri, 09 Jan 2026 22:32:55 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2430114.1767994942.1@sss.pgh.pa.us> Date: Fri, 09 Jan 2026 16:42:22 -0500 Message-ID: <2430115.1767994942@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Banck 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