Re: buildfarm instance bichir stuck

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

In response to

Responses

Browse pgsql-hackers by date

  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