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 1jK7pU-0001vB-EE for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 21:56:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jK7pS-0007Hq-Oe for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 21:56:50 +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 1jK7pR-0007Hj-6x for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 21:56:50 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jK7pM-000436-TV for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 21:56:48 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id EE0E47FA; Thu, 2 Apr 2020 17:56:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 02 Apr 2020 17:56:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilmari.org; h= from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=fm1; bh=ykjieyXjES2cXQ8wVIXklbhF+4 3zEGIJi0xIHrgd29E=; b=dI9q9LQ4M6ziPjDiWCNRiLmC+t/4T64g/UsAHc8U4U 9wzXfbxLTIsBTI8HEoDsLL2wGyCHVb7sdO0r5YQHXPpUT8cuVh5KTvCcNVFsOt5c +fZFxB47WrD5Qh8morZKgCg9+bfxNp2J0Hare6Sq8rkdZ1y9FDriQBsuVuLzTGXN YM+JI962qwR6YDJokBcA+h5ngdDDrUe4pvr/65iTIcy5HrJxzsbL0GOJWpMVxYH3 Zre2CFL2WRiepA3/LEOnrHKgRchxUsgU+xrH3zTw5pSzyxk+/0Fu4EiMsH65eaHZ D8Vu4KHjgCsBqn+3aPSC2mMh+Gnvc2k5slE9OAwVb7Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ykjiey XjES2cXQ8wVIXklbhF+43zEGIJi0xIHrgd29E=; b=RjedEJQYyJRxAo6dtGzRxv Wm5B9KfvPnIW4iRMhNnzelnNXozl0nBCymUXDeoaYMHPzM/vxw6qObYayBoAk6lw s+KrPvcOiw7FnKs4ELAOojmS1PpTWyya0Evtbi9FF49923asLVTZ0oG9Vqah+uel R7OuMan52WuGXfAejZ5dX9k/40Y59lZL8DyGrb1goZeN34BcuNkAbJ4KjWdMEpeH zjeOexrQyQBiKYlKw0g6xLE2TfGE7KuMTXt2aFMPt6n2BpDpYcDLm3RdML6DngvB HRITyYfT5+4/IwFt53Mmjy7hCfbaxXZiPJ16b2L4nt+6mmQooVnoDFWml7RLsqAA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdehgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufhffjgfkfgggtgesthdtredttderjeenucfhrhhomhepihhlmhgrrhhi sehilhhmrghrihdrohhrghculdffrghgfhhinhhnucfklhhmrghrihcuofgrnhhnshonkh gvrhdmnecukfhppeegiedrgeefrdduhedrvdehvdenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehilhhmrghrihesihhlmhgrrhhirdhorhhg X-ME-Proxy: Received: from wibble.ilmari.org (wibble.ilmari.org [46.43.15.252]) by mail.messagingengine.com (Postfix) with ESMTPA id 4576C3280066; Thu, 2 Apr 2020 17:56:41 -0400 (EDT) From: ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) To: Tom Lane 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 References: <84525289-3891-4368-9157-5452f53a6908@manitou-mail.org> <563.1585857846@sss.pgh.pa.us> Date: Thu, 02 Apr 2020 22:56:39 +0100 In-Reply-To: <563.1585857846@sss.pgh.pa.us> (Tom Lane's message of "Thu, 02 Apr 2020 16:04:06 -0400") Message-ID: <87y2rdtuug.fsf@wibble.ilmari.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Tom Lane writes: > "Daniel Verite" writes: >> These 2 tests need to allocate big chunks of contiguous memory, so they >> might fail for lack of memory on tiny machines, and even when not failing, >> they're pretty slow to run. Are they worth the trouble? > > 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? > It'd be great if there was a way to test get_bit/set_bit on large > indexes without materializing a couple of multi-hundred-MB objects. > Can't think of one offhand though. For this usecase it might make sense to express the limit in megabytes, and have a policy for how much memory tests can assume without explicit opt-in from the developer or buildfarm animal. - ilmari -- "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law