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 1glyG6-00004y-R2 for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Jan 2019 15:46:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1glyG5-0001LZ-89 for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Jan 2019 15:46:37 +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 1glyG4-0001LS-Tz for pgsql-hackers@lists.postgresql.org; Tue, 22 Jan 2019 15:46:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glyG1-0000kB-CY for pgsql-hackers@lists.postgresql.org; Tue, 22 Jan 2019 15:46:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x0MFkT0w006662; Tue, 22 Jan 2019 10:46:29 -0500 From: Tom Lane To: Fabien COELHO cc: PostgreSQL Developers Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD In-reply-to: References: <9427.1547701450@sss.pgh.pa.us> <21538.1547770868@sss.pgh.pa.us> <4615.1547792324@sss.pgh.pa.us> <29225.1547834182@sss.pgh.pa.us> <7879.1548015981@sss.pgh.pa.us> Comments: In-reply-to Fabien COELHO message dated "Tue, 22 Jan 2019 11:16:02 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6660.1548171989.1@sss.pgh.pa.us> Date: Tue, 22 Jan 2019 10:46:29 -0500 Message-ID: <6661.1548171989@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Fabien COELHO writes: > Given these results, I do not think that it is useful to change > random_zipfian TAP test parameter from 2.5 to something else. I'm not following this argument. The test case is basically useless for its intended purpose with that parameter, because it's highly likely that the failure mode it's supposedly checking for will be masked by the "random" function's tendency to spit out the same value all the time. We might as well drop zipfian from the test altogether and save ourselves some buildfarm cycles. regards, tom lane