| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robins Tharakan <tharakan(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: buildfarm instance bichir stuck |
| Date: | 2021-04-07 18:53:25 |
| Message-ID: | 9d3f425c-1b60-ed56-444b-c9d8487b72f1@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/7/21 1:07 PM, Tom Lane wrote:
> 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.
>
Yeah, I'll have a look. It's not simple for a bunch of reasons.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2021-04-07 19:09:24 | Re: multi-install PostgresNode fails with older postgres versions |
| Previous Message | Mark Dilger | 2021-04-07 18:40:05 | Re: multi-install PostgresNode fails with older postgres versions |