From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: buildfarm-members@postgresql.org
Subject: Re: buildfarm client release 4.18
In-reply-to: <d42f4f4f-8f0e-6e9d-0af2-e13d4ca1cc74@dunslane.net>
References: <d42f4f4f-8f0e-6e9d-0af2-e13d4ca1cc74@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Tue, 11 Oct 2016 20:24:34 -0400"
Date: Tue, 11 Oct 2016 20:51:09 -0400
Message-ID: <1874.1476233469@sss.pgh.pa.us>
Precedence: bulk
Sender: buildfarm-members-owner@postgresql.org

Andrew Dunstan <andrew@dunslane.net> writes:
>   * There is a new config parameter "wait_timeout", which defaults to
>     undefined. If it is set then any run that takes longer than the
>     specified number of seconds is aborted. That means that runs that
>     get stuck will time out, and the whole animal won't be stuck and
>     requiring manual intervention. My test animal has a setting of 3 *
>     3600, i.e. 3 hours. There is some possible danger in this, that we
>     might miss bugs that cause us to get stuck, so at least some animals
>     should not use this feature.

Hm, do you mean that if the timeout is exceeded, it just shuts down and
doesn't report the failure?  If there is a report I don't see how we'd
"miss" anything.

			regards, tom lane


-- 
Sent via buildfarm-members mailing list (buildfarm-members@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/buildfarm-members