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 1jK8DA-0002ns-OE for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 22:21:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jK8D7-0001YV-QC for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 22:21:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jK8D7-0001YO-JN for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 22:21:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jK8D5-0007R8-D7 for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 22:21:17 +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 032ML8fC022819; Thu, 2 Apr 2020 18:21:08 -0400 From: Tom Lane To: ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) cc: "Daniel Verite" , "movead.li\@highgo.ca" , "ashutosh.bapat" , "pgsql-hackers" Subject: Re: A bug when use get_bit() function for a long bytea string In-reply-to: <87y2rdtuug.fsf@wibble.ilmari.org> References: <84525289-3891-4368-9157-5452f53a6908@manitou-mail.org> <563.1585857846@sss.pgh.pa.us> <87y2rdtuug.fsf@wibble.ilmari.org> Comments: In-reply-to ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) message dated "Thu, 02 Apr 2020 22:56:39 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22817.1585866068.1@sss.pgh.pa.us> Date: Thu, 02 Apr 2020 18:21:08 -0400 Message-ID: <22818.1585866068@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> Yeah, I'd noticed those on previous readings of the patch. They'd almost >> certainly fail on some of our older/smaller buildfarm members, so they're >> not getting committed, even if they didn't require multiple seconds apiece >> to run (even on a machine with plenty of memory). It's useful to have >> them for initial testing though. > Perl's test suite has a similar issue with tests for handling of huge > strings, hashes, arrays, regexes etc. We've taken the approach of > checking the environment variable PERL_TEST_MEMORY and skipping tests > that need more than that many gigabytes. We currently have tests that > check for values from 1 all the way up to 96 GiB. > This would be trivial to do in the Postgres TAP tests, but something > similar might feasible in the pg_regress too? Meh. The memory is only part of it; the other problem is that multiple seconds expended in every future run of the regression tests is a price that's many orders of magnitude higher than the potential value of this test case. regards, tom lane