Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rlCHT-000hej-D3 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2024 18:27:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rlCHR-00BOTC-Ds for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2024 18:27:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rlCHR-00BOT4-4r for pgsql-hackers@lists.postgresql.org; Fri, 15 Mar 2024 18:27:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rlCHO-004haa-OM for pgsql-hackers@postgresql.org; Fri, 15 Mar 2024 18:27:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 42FIRRbS2528846; Fri, 15 Mar 2024 14:27:27 -0400 From: Tom Lane To: Heikki Linnakangas cc: Michael Paquier , pgsql-hackers Subject: Re: Weird test mixup In-reply-to: <9fc78855-bce0-463f-a045-892ee3e142f5@iki.fi> References: <10fd6cdd-c5d9-46fe-9fa1-7e661191309e@iki.fi> <2387221.1710454778@sss.pgh.pa.us> <2393552.1710458033@sss.pgh.pa.us> <44f5bf13-b46e-4b87-84de-2ac70fddbda0@iki.fi> <8e4cf596-dd70-432e-9068-16466ed596ed@iki.fi> <2498595.1710511222@sss.pgh.pa.us> <9fc78855-bce0-463f-a045-892ee3e142f5@iki.fi> Comments: In-reply-to Heikki Linnakangas message dated "Fri, 15 Mar 2024 17:56:14 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2528844.1710527247.1@sss.pgh.pa.us> Date: Fri, 15 Mar 2024 14:27:27 -0400 Message-ID: <2528845.1710527247@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Heikki Linnakangas writes: > On 15/03/2024 16:00, Tom Lane wrote: >> It may be even worse than it appears from the buildfarm status page. >> My animals were stuck in infinite loops that required a manual "kill" >> to get out of, and it's reasonable to assume there are others that >> will require owner intervention. Why would this test have done that, >> if the module failed to load? > The gin_incomplete_split test inserts rows until it hits the injection > point, at page split. There is a backstop, it should give up after 10000 > iterations, but that was broken. Fixed that, thanks for the report! Duh ... > Hmm, don't we have any timeout that would kill tests if they get stuck? AFAIK, the only constraint on a buildfarm animal's runtime is the wait_timeout setting, which is infinite by default, and was on my machines. (Not anymore ;-).) We do have timeouts in (most?) TAP tests, but this wasn't a TAP test. If this is a continuous-insertion loop, presumably it will run the machine out of disk space eventually, which could be unpleasant if there are other services running besides the buildfarm. I think I'll go notify the buildfarm owners list to check for trouble. Are there limits on the runtime of CI or cfbot jobs? Maybe somebody should go check those systems. regards, tom lane