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 1veJIP-00BiWy-2K for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 20:41:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1veJIJ-008YQN-1d for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jan 2026 20:41:16 +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 1veJIJ-008YQF-0Y for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 20:41:15 +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 1veJII-005813-0Q for pgsql-hackers@lists.postgresql.org; Fri, 09 Jan 2026 20:41:14 +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 609Kf3l52423165; Fri, 9 Jan 2026 15:41:03 -0500 From: Tom Lane To: Andrew Dunstan , michael.banck@credativ.de cc: pgsql-hackers@lists.postgresql.org Subject: Maybe BF "timedout" failures are the client script's fault? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2423126.1767991248.0@sss.pgh.pa.us> Date: Fri, 09 Jan 2026 15:41:03 -0500 Message-ID: <2423164.1767991263@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2423126.1767991248.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable We've been assuming that all the "timedout" failures on BF member fruitcrow were due to some wonkiness in the GNU/Hurd platform. I got suspicious about that though after noticing that there are a small number of such failures on other animals, eg [1][2][3]. In each case, the failure message claims it waited a good long time, which is at variance with the actually observed runtime. For instance [1] says "timed out after 14400 secs", but the actual total test runtime is only 01:24:28 according to the summary at the top of the page. 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. GNU/Hurd might just be more prone to that than other platforms. I propose the attached patch to the BF client to try to make this more robust. regards, tom lane [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dovenbird&dt=3D= 2025-11-14%2009%3A21%3A05 [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dconchuela&dt= =3D2025-10-17%2018%3A32%3A07 [3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dopaleye&dt=3D= 2026-01-08%2023%3A07%3A37 ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="make-bf-timeout-more-robust.patch"; charset="us-ascii" Content-ID: <2423126.1767991248.2@sss.pgh.pa.us> Content-Description: make-bf-timeout-more-robust.patch --- run_build.pl.orig 2025-11-25 07:47:25 +++ run_build.pl 2026-01-09 15:02:23 @@ -3415,7 +3415,13 @@ sub wait_timeout $SIG{$sig} = 'DEFAULT'; } $SIG{'TERM'} = \&silent_terminate; - sleep($wait_time); + # loop to absorb any unexpected signals without dying early + my $end_time = time + $wait_time; + while (time < $end_time) + { + my $delay = $end_time - time; + sleep($delay); + } print STDERR "Run timed out, terminating.\n"; my $sig = $usig[0] || 'TERM'; kill $sig, $main_pid; ------- =_aaaaaaaaaa0--