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 1gkNUT-0003T6-9U for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2019 06:18:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkNUR-0007Sx-KH for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2019 06:18:51 +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 1gkNUR-0007Sq-A4 for pgsql-hackers@lists.postgresql.org; Fri, 18 Jan 2019 06:18:51 +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 1gkNUO-0004sS-HE for pgsql-hackers@lists.postgresql.org; Fri, 18 Jan 2019 06:18:50 +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 x0I6IibG004616; Fri, 18 Jan 2019 01:18:44 -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: <21538.1547770868@sss.pgh.pa.us> References: <9427.1547701450@sss.pgh.pa.us> <21538.1547770868@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 17 Jan 2019 19:21:08 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4614.1547792324.1@sss.pgh.pa.us> Date: Fri, 18 Jan 2019 01:18:44 -0500 Message-ID: <4615.1547792324@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk BTW, if you're wondering why curculio is still failing the pgbench test, all is explained here: https://man.openbsd.org/srandom Or at least most is explained there. While curculio is unsurprisingly failing all four seeded_random tests, when I try it locally on an OpenBSD 6.4 installation, only the uniform, exponential, and gaussian cases reliably "fail". zipfian usually doesn't. It looks like the zipfian code almost always produces 4000 regardless of the seed value, though occasionally it produces 4001. Bad parameters for that algorithm, perhaps? regards, tom lane