Re: Maybe BF "timedout" failures are the client script's fault?

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Maybe BF "timedout" failures are the client script's fault?
Date: 2026-01-09 21:53:04
Message-ID: 20260109215304.GC21237@p46.dedyn.io;lightning.p46.dedyn.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, Jan 09, 2026 at 04:42:22PM -0500, Tom Lane wrote:
> Michael Banck <mbanck(at)gmx(dot)net> writes:
> > 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 ...

Looks like the server takes the timestamp of the logfile as an educated
guess when the particular stage finished:

https://github.com/PGBuildFarm/server-code/blob/main/cgi-bin/pgstatus.pl#L496

But this does not work when the stage hangs and gets terminated
externally, it seems no output is appended to the stage log in this case
by the buildfarm client and (at least for fruitcrow) neither by the
stage itself, so the server thinks the stage duration was whatever time
it took until the last piece of output before the hang.

Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message surya poondla 2026-01-09 22:01:10 Re: [PATCH][DOC][MINOR] Fix incorrect lexeme limit in textsearch docs
Previous Message Tom Lane 2026-01-09 21:42:22 Re: Maybe BF "timedout" failures are the client script's fault?