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 1nF5cp-00084q-U3 for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Feb 2022 02:44:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nF5co-0002MQ-2q for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Feb 2022 02:44:02 +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 1nF5cn-0002MH-Po for pgsql-hackers@lists.postgresql.org; Wed, 02 Feb 2022 02:44:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nF5ck-0005ss-TJ for pgsql-hackers@postgresql.org; Wed, 02 Feb 2022 02:44:00 +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 2122hr6M1049715; Tue, 1 Feb 2022 21:43:53 -0500 From: Tom Lane To: Thomas Munro cc: Andres Freund , Michael Paquier , Andrew Dunstan , Anastasia Lubennikova , pgsql-hackers Subject: Re: A test for replay of regression tests In-reply-to: References: <20211209213605.6lwb7o2kzdla34qk@alap3.anarazel.de> <20220114234947.av4kkhuj7netsy5r@alap3.anarazel.de> <20220121194827.7eau4ulhrfol3npd@alap3.anarazel.de> Comments: In-reply-to Thomas Munro message dated "Wed, 02 Feb 2022 13:59:56 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1049713.1643769833.1@sss.pgh.pa.us> Date: Tue, 01 Feb 2022 21:43:53 -0500 Message-ID: <1049714.1643769833@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > Seen again today on prairiedog. Erm, scratch that idea, HS feedback > interferes with test results. I guess max_standby_streaming_delay > should be increased to 'forever', like in the attached, since pg_dump > runs for a very long time on prairiedog: FWIW, I'd vote for keeping a finite timeout, but making it say ten minutes. If the thing gets stuck for some reason, you don't really want the test waiting forever. (Some buildfarm animals have overall-test-time limits, but I think it's not the default, and the behavior when that gets hit is pretty unfriendly anyway -- you don't get any report of the run at all.) regards, tom lane