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: | Raw Message | Whole Thread | 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 |