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.89) (envelope-from ) id 1gVmld-00029B-Up for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Dec 2018 00:16:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVmla-00007f-Lu for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Dec 2018 00:16:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVmla-00007Y-3L for pgsql-hackers@lists.postgresql.org; Sun, 09 Dec 2018 00:16:14 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVmlS-0003OS-S7 for pgsql-hackers@postgresql.org; Sun, 09 Dec 2018 00:16:12 +0000 Received: by mail-pl1-x630.google.com with SMTP id e5so3507061plb.5 for ; Sat, 08 Dec 2018 16:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=bID3buKiiQV+9NLwj42RaEnX1gGoNig2PE/F/r41PX8=; b=c5Qo7b8vhOJIUfacKhJDZCfHpdQva8zoym9UJWgKn2ikAmu5f1yifqhBHcWtirQE4x 5MD/aEVPJ8umpH6R96sZSFYhpiaauHB0KZWvEslCh7OCUVNNKAoM5HmXwy78J4dAQzj3 2msVC2V1pUjeOXv9Xxdt254gHeaKgrfsQL57s= 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:subject:message-id:mime-version :content-disposition:user-agent; bh=bID3buKiiQV+9NLwj42RaEnX1gGoNig2PE/F/r41PX8=; b=QJSmqYruyXyecRKk+LB6HwCS6XrDGKh3gnUdi0DJV746+qd3FqQkKvm4Jm94Sx0gte Jccv4INy9my80Y0SBbXJFt4spc0dMrgmiE0cUWP/Nsuz5/FcyN7JtVGIKqmi2tiBk3Ar k/9izuNzm++/2w16c+6rYjUJn0CTugBMMRiYXwk7IAlcy214f8TUgt1Zsc40GrBZWt47 HlRkddunXlBs5EECJDWPBkqc5wOM6sDOETUovlv7QjyLbMjZ//jxwAFOKBAoi2zcR0LE xc1o2Dl46IU2e7Oi2AoWI6RKPWMcVL2ESE8TwjEW1IdUhlFki/N4No3RyHY4WoWl0sHE V4xQ== X-Gm-Message-State: AA+aEWYH4H1LuWLQ+ivKaJKG7bC/zBAK/uabg+O83JneQ1zm62xTtUPW /+mDpoKAgy/Bxseusb03MMWDLpKJsj4= X-Google-Smtp-Source: AFSGD/WQhAQ0gbeCa5h4j9Rfu6HZm+1UiFohtTC1J2h96cDuNWZfxnXR/yxUHtWrlId2o/BdsY7Q4A== X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11mr7329368plb.332.1544314564625; Sat, 08 Dec 2018 16:16:04 -0800 (PST) Received: from rfd.leadboat.com (c-73-158-248-138.hsd1.ca.comcast.net. [73.158.248.138]) by smtp.gmail.com with ESMTPSA id t67sm14529985pfd.90.2018.12.08.16.16.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 16:16:03 -0800 (PST) Date: Sat, 8 Dec 2018 16:16:01 -0800 From: Noah Misch To: pgsql-hackers@postgresql.org Subject: Too-short timeouts in test code Message-ID: <20181209001601.GC2973271@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We've had more buildfarm failures due to hard-coded, short timeouts: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2018-10-13%2021%3A06%3A58 10s timeout while running pg_recvlogical http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2018-12-03%2005%3A52%3A12 30s timeout while running pg_recvlogical https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2018-11-30%2014%3A31%3A18 60s timeout in isolationtester try_complete_step() The 180s timeout in poll_query_until has been trouble-free since 2a0f89c introduced it two years ago. I plan to raise the timeouts in question to 180s, as attached. --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test-timeout-180s-v1.patch" diff --git a/src/test/isolation/README b/src/test/isolation/README index bea278a..780b6dc 100644 --- a/src/test/isolation/README +++ b/src/test/isolation/README @@ -108,8 +108,8 @@ 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 60 seconds. If the cancel doesn't work, isolationtester will exit -uncleanly after a total of 75 seconds of wait time. Testing invalid +after 180 seconds. If the cancel doesn't work, isolationtester will exit +uncleanly after a total of 200 seconds of wait time. 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. diff --git a/src/test/isolation/isolationtester.c b/src/test/isolation/isolationtester.c index 7df67da..9134b05 100644 --- a/src/test/isolation/isolationtester.c +++ b/src/test/isolation/isolationtester.c @@ -783,15 +783,15 @@ try_complete_step(Step *step, int flags) td += (int64) current_time.tv_usec - (int64) start_time.tv_usec; /* - * After 60 seconds, try to cancel the query. + * After 180 seconds, try to cancel the query. * * If the user tries to test an invalid permutation, we don't want * to hang forever, especially when this is running in the - * buildfarm. So try to cancel it after a minute. This will - * presumably lead to this permutation failing, but remaining - * permutations and tests should still be OK. + * buildfarm. This will presumably lead to this permutation + * failing, but remaining permutations and tests should still be + * OK. */ - if (td > 60 * USECS_PER_SEC && !canceled) + if (td > 180 * USECS_PER_SEC && !canceled) { PGcancel *cancel = PQgetCancel(conn); @@ -808,15 +808,15 @@ try_complete_step(Step *step, int flags) } /* - * After 75 seconds, just give up and die. + * After 200 seconds, just give up and die. * * Since cleanup steps won't be run in this case, this may cause * later tests to fail. That stinks, but it's better than waiting * forever for the server to respond to the cancel. */ - if (td > 75 * USECS_PER_SEC) + if (td > 200 * USECS_PER_SEC) { - fprintf(stderr, "step %s timed out after 75 seconds\n", + fprintf(stderr, "step %s timed out after 200 seconds\n", step->name); exit_nicely(); } diff --git a/src/test/recovery/t/006_logical_decoding.pl b/src/test/recovery/t/006_logical_decoding.pl index 884b0ae..c23cc4d 100644 --- a/src/test/recovery/t/006_logical_decoding.pl +++ b/src/test/recovery/t/006_logical_decoding.pl @@ -72,7 +72,7 @@ my $endpos = $node_master->safe_psql('postgres', print "waiting to replay $endpos\n"; my $stdout_recv = $node_master->pg_recvlogical_upto( - 'postgres', 'test_slot', $endpos, 10, + 'postgres', 'test_slot', $endpos, 180, 'include-xids' => '0', 'skip-empty-xacts' => '1'); chomp($stdout_recv); @@ -84,7 +84,7 @@ $node_master->poll_query_until('postgres', ) or die "slot never became inactive"; $stdout_recv = $node_master->pg_recvlogical_upto( - 'postgres', 'test_slot', $endpos, 10, + 'postgres', 'test_slot', $endpos, 180, 'include-xids' => '0', 'skip-empty-xacts' => '1'); chomp($stdout_recv); diff --git a/src/test/recovery/t/010_logical_decoding_timelines.pl b/src/test/recovery/t/010_logical_decoding_timelines.pl index 4fbd386..e582b20 100644 --- a/src/test/recovery/t/010_logical_decoding_timelines.pl +++ b/src/test/recovery/t/010_logical_decoding_timelines.pl @@ -183,7 +183,7 @@ my $endpos = $node_replica->safe_psql('postgres', $stdout = $node_replica->pg_recvlogical_upto( 'postgres', 'before_basebackup', - $endpos, 30, + $endpos, 180, 'include-xids' => '0', 'skip-empty-xacts' => '1'); --cWoXeonUoKmBZSoM--