Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jBDxH-0005zM-Ip for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2020 08:40:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jBDxG-0008MH-9j for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2020 08:40:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jBDxG-0008MA-1A for pgsql-hackers@lists.postgresql.org; Mon, 09 Mar 2020 08:40:06 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jBDxD-00017r-BS for pgsql-hackers@postgresql.org; Mon, 09 Mar 2020 08:40:05 +0000 Received: by mail-lf1-x141.google.com with SMTP id q9so279473lfc.10 for ; Mon, 09 Mar 2020 01:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PrNjrYroetxX0YIypaYt8fRGLH2KEcLsZAWobH8fz5A=; b=ShVIiWkjaS1xGIl6fwt8SgV10XH+kMKOZi45lkQYzUNEacqygvh2oYzeQueIgV5e1F wnBW+RnSK58B4fIGxMgIodSCKE/soGlJwU3gHm7oIAhI2EamSjCE/oaVEv7/7V9+4vG8 HrXtapmjruoXquKhPgc2pC/F888Ql5CS2PKryMzq6spR07bKq3lmqfpf2INR9e1LlYbf fipF/VDoj82JvKJckEXVszl+G+Of3He+AGouUhXP8SoPwAjzRlQtMe0o0T9Q8xG5ZqW/ Kz0hevBDbKTJeDMEMPQpbB3Vckpjlx6oU2po+rTjBfEaL7pN/3jeDddQpZBrOudOXc85 v9IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PrNjrYroetxX0YIypaYt8fRGLH2KEcLsZAWobH8fz5A=; b=DIniSonm/QEXfuNbx9/0Qe/qH8Q6HlvKLh0wIhwPg3az58uRYt52X0P0jwm7/+eHRb Ll/vrt1wKkWECua7Xk1tyW0V8dDMu8YSQPG4rR1FpJ04gptvXCh0aftTCzXICTy17+Ga zAHi9N7A0hyBbmipJl2uNgBQmd8B6/n/ldL+oqwRMCIXR2POjX8h9WSGkUBi7t9He3nx l4hcMUkHyUAmD83bFhvA7xNcriLwRbVFwDNblPe2obYZnDl/siF0Xr97XvoHKt69Ggu8 BeBHOCu0ig9m2UEe6e19qyZmt5VSaR5iQN+UH/MBMmj+pfP62VAM9jqo3zC4/ejjAOth VKBg== X-Gm-Message-State: ANhLgQ3EZz5jVmAvkKK9lJLI0onTSjskPbS7rIZK4wYCne/Evki1moJq ZhJAPh8wQ78P3kOoVlip+hE= X-Google-Smtp-Source: ADFU+vuCwKhOulLcyC0sgACGArY0hxE37Dy6jrcs94Zfy4RYmt9Gw32JDVembRrEh5B0JvnHVcW18Q== X-Received: by 2002:a05:6512:1116:: with SMTP id l22mr8945878lfg.70.1583743202583; Mon, 09 Mar 2020 01:40:02 -0700 (PDT) Received: from nol (82-64-124-11.subs.proxad.net. [82.64.124.11]) by smtp.gmail.com with ESMTPSA id m1sm21611371lfo.26.2020.03.09.01.40.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2020 01:40:02 -0700 (PDT) Date: Mon, 9 Mar 2020 09:39:59 +0100 From: Julien Rouhaud To: Michael Paquier Cc: Tom Lane , Michael Paquier , pgsql-hackers Subject: Re: Add an optional timeout clause to isolationtester step. Message-ID: <20200309083959.GA30818@nol> References: <20200303080642.GA1890@paquier.xyz> <20200303092551.GB1890@paquier.xyz> <20200304051510.GE2593@paquier.xyz> <20200305035354.GQ2593@paquier.xyz> <20200306131547.GA2904@nol> <20200307014142.GC1531@paquier.xyz> <20200307061615.c47sju2bytuiaazv@nol> <8441.1583595994@sss.pgh.pa.us> <20200309074727.GE96055@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200309074727.GE96055@paquier.xyz> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Mar 09, 2020 at 04:47:27PM +0900, Michael Paquier wrote: > On Sat, Mar 07, 2020 at 10:46:34AM -0500, Tom Lane wrote: > > The arbitrarily-set timeouts that exist in some of the isolation tests > > are horrid kluges that have caused us lots of headaches in the past > > and no doubt will again in the future. Aside from occasionally failing > > when a machine is particularly overloaded, they cause the tests to > > take far longer than necessary on decently-fast machines. So ideally > > we'd get rid of those entirely in favor of some more-dynamic approach. > > Admittedly, I have no proposal for what that would be. But adding yet > > more ways to set a (guaranteed-to-be-wrong) timeout seems like the > > wrong direction to be going in. What's the actual need that you're > > trying to deal with? > > As a matter of fact, the buildfarm member petalura just reported a > failure with the isolation test "timeouts", the machine being > extremely slow: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=petalura&dt=2020-03-08%2011%3A20%3A05 > > test timeouts ... FAILED 60330 ms > [...] > -step update: DELETE FROM accounts WHERE accountid = 'checking'; > -step update: <... completed> > +step update: DELETE FROM accounts WHERE accountid = 'checking'; > ERROR: canceling statement due to statement timeout Indeed. I guess we could add some kind of environment variable facility in isolationtester to let slow machine owner put a way bigger timeout without making the test super slow for everyone else, but that seems overkill for just one test, and given the other thread about deploying REL_11 build-farm client, that wouldn't be an immediate fix either.