Re: buildfarm instance bichir stuck

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robins Tharakan <tharakan(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: buildfarm instance bichir stuck
Date: 2021-04-07 17:07:59
Message-ID: 1598686.1617815279@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robins Tharakan <tharakan(at)gmail(dot)com> writes:
> Not sure if many agree but 2 things stood out here:
> 1) Buildfarm never got the message that a commit broke an instance. Ideally
> I'd have expected buildfarm to have an optimistic timeout that could have
> helped - for e.g. right now, the CREATE DATABASE is still stuck since 18
> hrs.

As far as that goes, you can set wait_timeout in the animal's config
to something comfortably more than the longest run time you expect.
It doesn't default to enabled though, possibly because picking a
one-size-fits-all value would be impossible.

I do use it on some of my flakier dinosaurs, and I've noticed that
when it does kick in, the buildfarm run just stops dead and no report
is sent to the BF server. That has advantages in not cluttering the
BF status with run-failed-because-of-$weird_problem issues, but it
doesn't help from the standpoint of noticing when your animal is stuck.
Maybe it'd be better to change that behavior.

(I can also attest from personal experience that what had been a
comfortable amount of slop when you picked it tends to become less
so over time. Consider yourself warned.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-07 17:09:54 Re: Minimal logical decoding on standbys
Previous Message vignesh C 2021-04-07 17:07:34 Re: Identify missing publications from publisher while create/alter subscription.