Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngIvn-0005n5-Tl for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2022 04:24:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ngIvm-00020z-Pu for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2022 04:24:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngIvm-00020c-BI for pgsql-hackers@lists.postgresql.org; Mon, 18 Apr 2022 04:24:06 +0000 Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ngIvj-0000c7-HC for pgsql-hackers@postgresql.org; Mon, 18 Apr 2022 04:24:05 +0000 Received: by mail-qt1-x830.google.com with SMTP id f14so915135qtq.1 for ; Sun, 17 Apr 2022 21:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qYzSxZsWy1wXmC16oP1hmCrpvQ6uis7GrWwlAwpFtY0=; b=Y+0yoWQm088nkuLPwVJ3c3Z2V2ZZQ1rfh6ahkOfTyaGj0MH/YHfB2tel1GkxUtPhsV LF71MrRCbI+AbR2uHysutOioa0Nt/dseWtMHZYmytMMNoWGmnX1kUci7JCxgBCM6jIjv o02PWcJ1JNR2kFTWNkswKbOPdIep21nHTM314= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qYzSxZsWy1wXmC16oP1hmCrpvQ6uis7GrWwlAwpFtY0=; b=DVjNWqLUr0CXyOWS/4UadvfXPeQlGug8GDBpHg8fQWz5vyv4xhgV+141o/5KNWvEur FCNIkvlPZ9nYcCyV9lqFJlvZ6mjzTKtVuIbBva06idmKxtHRwQrZrYzPlp4St6sfRo1v meRPsZnYwGbnWa1i1/bYIRC2t9EGi21JzO6CsozOQY1Cj2dxPBI+W7/NJPAr9MK+z8pg 6Ac80kMIEYg7lOEVbfFtrV3PSRLjsh0O9Ga8KVoKptctgG7u5jryWdEIkP2fsY0ZBGIP H0u01ejoHhA84+Hw14V7duoSQDDFo5qo2zdEZ3xH9at3kCscr1vkvjrdhLd91kcuQ+rv isCw== X-Gm-Message-State: AOAM530gix6BbBQlNxMqLX//QH6lqiZYV5VorRJJSOhXyrKPvhOKZM36 vPTNyo7WK5/jGtXxIBqyal9D8w== X-Google-Smtp-Source: ABdhPJxY9MxOCYb7wz64CRc8j18+BSVkTBH69fQXz9luApTRZZOlItrzHBWlRZ7xVHTM8WeJrY0hIw== X-Received: by 2002:a05:622a:349:b0:2f1:ffc2:821a with SMTP id r9-20020a05622a034900b002f1ffc2821amr1662356qtw.36.1650255842582; Sun, 17 Apr 2022 21:24:02 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id n8-20020ac85a08000000b002f1fc230725sm1759543qta.31.2022.04.17.21.24.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Apr 2022 21:24:02 -0700 (PDT) Date: Sun, 17 Apr 2022 21:23:59 -0700 From: Noah Misch To: Tom Lane Cc: Andres Freund , pgsql-hackers@postgresql.org Subject: Re: Timeout control within tests Message-ID: <20220418042359.GD1118930@rfd.leadboat.com> References: <20220218052842.GA3627003@rfd.leadboat.com> <20220218054825.vhoiv2f7vgwdsnnb@alap3.anarazel.de> <20220218071911.GB3506226@rfd.leadboat.com> <3949563.1645198012@sss.pgh.pa.us> <20220219024136.GA3670392@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20220219024136.GA3670392@rfd.leadboat.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (I pushed the main patch as f2698ea, on 2022-03-04.) On Fri, Feb 18, 2022 at 06:41:36PM -0800, Noah Misch wrote: > On Fri, Feb 18, 2022 at 10:26:52AM -0500, Tom Lane wrote: > > Noah Misch writes: > > > On Thu, Feb 17, 2022 at 09:48:25PM -0800, Andres Freund wrote: > > >> Meson's test runner has the concept of a "timeout multiplier" for ways of > > >> running tests. Meson's stuff is about entire tests (i.e. one tap test), so > > >> doesn't apply here, but I wonder if we shouldn't do something similar? > > > > > Hmmm. It is good if the user can express an intent that continues to make > > > sense if we change the default timeout. For the buildfarm use case, a > > > multiplier is moderately better on that axis (PG_TEST_TIMEOUT_MULTIPLIER=100 > > > beats PG_TEST_TIMEOUT_DEFAULT=18000). For the hacker use case, an absolute > > > value is substantially better on that axis (PG_TEST_TIMEOUT_DEFAULT=3 beats > > > PG_TEST_TIMEOUT_MULTIPLIER=.016666). > > > > FWIW, I'm fairly sure that PGISOLATIONTIMEOUT=300 was selected after > > finding that smaller values didn't work reliably in the buildfarm. > > Now maybe 741d7f1 fixed that, but I wouldn't count on it. So while I > > approve of the idea to remove PGISOLATIONTIMEOUT in favor of using this > > centralized setting, I think that we might need to have a multiplier > > there, or else we'll end up with PG_TEST_TIMEOUT_DEFAULT set to 300 > > across the board. Perhaps the latter is fine, but a multiplier seems a > > bit more flexible. > > The PGISOLATIONTIMEOUT replacement was 2*timeout_default, so isolation suites > would get 2*180s=360s. (I don't want to lower any default timeouts, but I > don't mind raising them.) In a sense, PG_TEST_TIMEOUT_DEFAULT is a multiplier > with as many sites as possible multiplying it by 1. The patch has multiples > at two code sites. Here's the PGISOLATIONTIMEOUT replacement patch. I waffled on whether to back-patch. Since it affects only isolation suite testing, only on systems too slow for the default timeout, it's not a major decision. I currently plan not to back-patch, since slow systems that would have wanted a back-patch can just set both variables. --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="PGISOLATIONTIMEOUT-decom-v1.patch" Author: Noah Misch Commit: Noah Misch Replace PGISOLATIONTIMEOUT with 2 * PG_TEST_TIMEOUT_DEFAULT. Now that the more-generic variable exists, use it. Reviewed by FIXME. Discussion: https://postgr.es/m/20220219024136.GA3670392@rfd.leadboat.com diff --git a/src/test/isolation/README b/src/test/isolation/README index 8457a56..5818ca5 100644 --- a/src/test/isolation/README +++ b/src/test/isolation/README @@ -47,10 +47,10 @@ pg_isolation_regress is a tool similar to pg_regress, but instead of using psql to execute a test, it uses isolationtester. It accepts all the same command-line arguments as pg_regress. -By default, isolationtester will wait at most 300 seconds (5 minutes) +By default, isolationtester will wait at most 360 seconds (6 minutes) for any one test step to complete. If you need to adjust this, set -the environment variable PGISOLATIONTIMEOUT to the desired timeout -in seconds. +the environment variable PG_TEST_TIMEOUT_DEFAULT to half the desired +timeout in seconds. Test specification @@ -138,10 +138,11 @@ Each step may contain commands that block until further action has been taken deadlock). A test that uses this ability must manually specify valid permutations, i.e. those that would not expect a blocked session to execute a command. If a test fails to follow that rule, isolationtester will cancel it -after PGISOLATIONTIMEOUT seconds. If the cancel doesn't work, isolationtester -will exit uncleanly after a total of twice PGISOLATIONTIMEOUT. Testing -invalid permutations should be avoided because they can make the isolation -tests take a very long time to run, and they serve no useful testing purpose. +after 2 * PG_TEST_TIMEOUT_DEFAULT seconds. If the cancel doesn't work, +isolationtester will exit uncleanly after a total of 4 * +PG_TEST_TIMEOUT_DEFAULT. Testing invalid permutations should be avoided +because they can make the isolation tests take a very long time to run, and +they serve no useful testing purpose. Note that isolationtester recognizes that a command has blocked by looking to see if it is shown as waiting in the pg_locks view; therefore, only diff --git a/src/test/isolation/isolationtester.c b/src/test/isolation/isolationtester.c index 12179f2..095db8f 100644 --- a/src/test/isolation/isolationtester.c +++ b/src/test/isolation/isolationtester.c @@ -46,7 +46,7 @@ static int nconns = 0; static bool any_new_notice = false; /* Maximum time to wait before giving up on a step (in usec) */ -static int64 max_step_wait = 300 * USECS_PER_SEC; +static int64 max_step_wait = 360 * USECS_PER_SEC; static void check_testspec(TestSpec *testspec); @@ -128,12 +128,12 @@ main(int argc, char **argv) conninfo = "dbname = postgres"; /* - * If PGISOLATIONTIMEOUT is set in the environment, adopt its value (given - * in seconds) as the max time to wait for any one step to complete. + * If PG_TEST_TIMEOUT_DEFAULT is set, adopt its value (given in seconds) + * as half the max time to wait for any one step to complete. */ - env_wait = getenv("PGISOLATIONTIMEOUT"); + env_wait = getenv("PG_TEST_TIMEOUT_DEFAULT"); if (env_wait != NULL) - max_step_wait = ((int64) atoi(env_wait)) * USECS_PER_SEC; + max_step_wait = 2 * ((int64) atoi(env_wait)) * USECS_PER_SEC; /* Read the test spec from stdin */ spec_yyparse(); --7AUc2qLy4jB3hD7Z--