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 1gVolz-0000Mt-3Z for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Dec 2018 02:24:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVolx-0002nt-Cq for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Dec 2018 02:24:45 +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 1gVolw-0002nm-Tj for pgsql-hackers@lists.postgresql.org; Sun, 09 Dec 2018 02:24:45 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVolu-0006LD-AH for pgsql-hackers@postgresql.org; Sun, 09 Dec 2018 02:24:44 +0000 Received: by mail-pl1-x644.google.com with SMTP id a14so3570044plm.12 for ; Sat, 08 Dec 2018 18:24:41 -0800 (PST) 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=I+LxD8RNWioT9ElSqbbLvkLNJBi7e3A9kM6w6bQUXOE=; b=Zen6bnUzSfRGa9lqhxokkVjo3S6t/hNBr2HBFVH4ruhcg5Nc7oeEja2bXKTfZ1fyl9 7ImPINqfPlWwDyVJ7yQxnWCb8asndVFb4isCx7m95/+rrbRz+iRoCKfVfBz9lUry/hBT 1iEH8rJY5ZftAMP72fxJMIZviWcJ7xmBj5HTk= 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:user-agent; bh=I+LxD8RNWioT9ElSqbbLvkLNJBi7e3A9kM6w6bQUXOE=; b=ojtCJvCgvE16kym6jMLi1jmP5p5p3GAldCGu9PVARVPNA5kZ1Vf1fUgJw88v1+/YOA wP4tznLb9Xc4Ivi0xiUjK+ZnTwkwzTKdGH2IBdU6HUkFfwlFs1noiagF3Dgc87Jx+w4O sDhvhmeGwjNrKZrCXt3tz8Q7D6q2gp0w/9rKr6rtC7fhdAC+E71DGE9wObKMaJehd6OS K+9ryh7ezg6HwRhT2o1eDhQAnA25kRCcMZt+TuuvzRWQb2lRthMyA4VlcgK5og50eRlC MCT5zZyxxwaZF1I4kHmcwoXMq/2jIJXMoqE/axb3IeXBBcvn6njaK8dVoZpKov/A3QoP i17w== X-Gm-Message-State: AA+aEWaS32oJo1oxTvTthniqUApy479aEuei/ymjfMQMI6q1YJIVjPWU yemnecS1rEYPdEBjnPQzSM2HOHOZ4i8= X-Google-Smtp-Source: AFSGD/WNrE72HWufQI2nkd9AFUJsPM5eUQAtk7IFfVdPItajBSogygSyyPwkgNjsR3NexDH5bxAsTw== X-Received: by 2002:a17:902:298a:: with SMTP id h10mr7546952plb.312.1544322278630; Sat, 08 Dec 2018 18:24:38 -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 t29sm11289539pfa.158.2018.12.08.18.24.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Dec 2018 18:24:37 -0800 (PST) Date: Sat, 8 Dec 2018 18:24:35 -0800 From: Noah Misch To: Michael Paquier Cc: pgsql-hackers@postgresql.org Subject: Re: Too-short timeouts in test code Message-ID: <20181209022435.GE2973271@rfd.leadboat.com> References: <20181209001601.GC2973271@rfd.leadboat.com> <20181209021412.GC1833@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181209021412.GC1833@paquier.xyz> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Dec 09, 2018 at 11:14:12AM +0900, Michael Paquier wrote: > On Sat, Dec 08, 2018 at 04:16:01PM -0800, Noah Misch wrote: > > @@ -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'); > > Instead of allowing callers of pg_recvlogical_upto() to define the > timeout they want, perhaps it would be better to hardcode the timeout > limit within the routine? pg_recvlogical_upto() has the ability to make timeout non-fatal, by calling it in an array context. No in-tree test uses that. Out-of-tree code using that feature would likely benefit from the ability to set timeout duration. Hence, I'm inclined not remove the timeout duration parameter.