Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bRYcC-00053s-Oj for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2016 05:39:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bRYcC-0008Lr-Bj for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2016 05:39:44 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bRYaq-0006qv-EJ for pgsql-hackers@postgresql.org; Mon, 25 Jul 2016 05:38:20 +0000 Received: from mail-qk0-x230.google.com ([2607:f8b0:400d:c09::230]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bRYan-0005WD-DC for pgsql-hackers@postgresql.org; Mon, 25 Jul 2016 05:38:19 +0000 Received: by mail-qk0-x230.google.com with SMTP id s63so147199443qkb.2 for ; Sun, 24 Jul 2016 22:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=d0KMvEHgIw/71/49BUUqSRzE6Nf7SkEjFIa3FSH29+Y=; b=JT62i86BsNjlkwg3RLcXIWoR4vwobLkk+jHgHOJ4rofgqZ3ODcTt0i9biuSqetK3Fe OqJB3Baro0Hr17MMpIT0SYgiRNPqLtCOKHIXHzVSbam14XSMUUeUSmJLZPRi5mSq9AO1 sF8SO2CwLgL76Zst9UJTP6Y2/OjZgBDFYM8vmF4lnyJvCD17AfXZQ1xfhq64Id/6NMGn ViWsQwx2yTPhpCSSHF7pWGH6HnBR9DzZjWOTEzk1HaVJ/diBABG4Msl0IWX7FjvcWqs6 T+BJZcjJSffLIopo+3dZJqs2WpFUaj64f0bejG3c+mVo+2fgwA2WvaYby5n2mrZNYjLx xsCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=d0KMvEHgIw/71/49BUUqSRzE6Nf7SkEjFIa3FSH29+Y=; b=bz+XOLffteh9JVKBYhsGi3S5AtczAZ9dEutE9XUI8O2P1pInJyKmtHgim2zXmGCg27 iqsEH/Dse0v5C/Euvo+Se4l+L+ABTl8fLehCMacmQnCmMCofPG5NWpHdnUiL/vrj77/I O5uvmBda/JdhzaPOZFvDxHv9agYAM5ElCKJP28Bz+8MM1t5tR7yT1Mn3Ko+ECjyhVY5C xYnrKgg+nB8sS1h8mCnESvIcfSRa8P0hLks905zyNjq1D6Wdg7JipC2ecjlZqXhhnqY3 jiSDBinVo84wa9r2+io3zJuKIxXjmfbY7XLrNImZJQbTNTNsuO/J/dz9OrlEyw83kGlr /Fig== X-Gm-Message-State: AEkoouvMutM2zVicYqfmSula/LFM5Yb7ZpZYZMjzBRENCr/0F3SzFfHDbbo44vZ6X3vUSKta X-Received: by 10.55.200.137 with SMTP id t9mr20998458qkl.128.1469425096237; Sun, 24 Jul 2016 22:38:16 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([190.91.47.82]) by smtp.gmail.com with ESMTPSA id 2sm14415468qta.2.2016.07.24.22.38.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jul 2016 22:38:15 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 0DC865BC; Mon, 25 Jul 2016 01:38:10 -0400 (CLT) Date: Mon, 25 Jul 2016 01:38:10 -0400 From: Alvaro Herrera To: Michael Paquier Cc: PostgreSQL mailing lists Subject: Re: Increasing timeout of poll_query_until for TAP tests Message-ID: <20160725053810.GA259556@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -1.1 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Michael Paquier wrote: > Lately hamster is failing every 4/5 days on the recovery regression > tests in 003 covering the recovery targets, with that: > # Postmaster PID for node "standby_2" is 20510 > # > Timed out while waiting for standby to catch up at > t/003_recovery_targets.pl line 36. > > Which means that poll_for_query timed out for the standby to catch up.. > > Here is an example of test that failed: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2016-07-24%2016%3A00%3A07 Yeah, thanks, pushed. However this doesn't explain all the failures we see: 1) In http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2016-07-14%2016%3A00%3A06 we see the pg_basebackup test failing. I suppose that failure is also because of slowness, though of course this patch won't fix it. 2) In http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hamster&dt=2016-06-29%2016%3A00%3A06&stg=recovery-check we see a completely different failure: error running SQL: 'psql::1: ERROR: relation "tab_int" does not exist LINE 1: SELECT count(*) FROM tab_int ^' while running 'psql -XAtq -d port=52824 host=/tmp/or2xHglniM dbname=postgres -f - -v ON_ERROR_STOP=1' at /home/buildfarm/data/buildroot/HEAD/pgsql.build/src/test/recovery/../../../src/test/perl/PostgresNode.pm line 1166. Do we have an explanation for this one? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers