Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMgaJ-0006dI-5g for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Dec 2017 20:46:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMgaI-0003zA-O8 for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Dec 2017 20:46:26 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMgaI-0003z0-Be for pgsql-bugs@lists.postgresql.org; Wed, 06 Dec 2017 20:46:26 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eMgaB-0007ZE-Ec for pgsql-bugs@postgresql.org; Wed, 06 Dec 2017 20:46:25 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9426920C87; Wed, 6 Dec 2017 15:46:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 06 Dec 2017 15:46:17 -0500 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-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jdwg3WFioBpfYUjo5hWdN7MvJbcNZ 1XSeX16HTo/H8c=; b=HTXIB+HdSdaQhDO9C5xbWonkTWbRWroJ92jWb3eIOzVyx WgeVS9TM9V8kYrggfSpt29ZMvwidZERJMReBHXFAtRTJEXVezhgjRmpWpNRi/krq SiFVfTKIwSxm9vWFYEPNtSEC+za/VKB0J5as5Rc6NnpxnfRAHwI9omY/TOOQANRw n2uoD/kgcddcgqT3btqBkYSE67sgWm7lRHCC+3VpOkuxFglKCaZH5hdiQthE/6KE su3j3F9UzEd+ybcSra2e++vIRp6j2jNylTGPwhHS/h2nXCJVsFLeAVbkldm5l1CR M7ryPAltcaTAfNV3778Z1M/f9wXVnNq7L7uJTfwQQ== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 4C026240F8; Wed, 6 Dec 2017 15:46:17 -0500 (EST) Date: Wed, 6 Dec 2017 12:46:16 -0800 From: Andres Freund To: Tomas Vondra Cc: "Todd A. Cook" , Tom Lane , Thomas Munro , PostgreSQL Bugs Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop Message-ID: <20171206204616.wcect35fuj5gjde2@alap3.anarazel.de> References: <20171127221041.mezzysc4zcfsqkyc@alap3.anarazel.de> <17357.1511841783@sss.pgh.pa.us> <9cd29b81-7ba1-91a2-f491-9014f4ac87e6@blackducksoftware.com> <2a76784c-06cb-46ec-35be-9895d144b839@2ndquadrant.com> <263b03b1-3e1c-49ca-165a-8ac6751419c4@2ndquadrant.com> <20171206193545.3imvbfwjgrmuho3s@alap3.anarazel.de> <790BC80E-D8E5-499B-A1E3-8EE0752B53ED@anarazel.de> <06523583-b9c5-1424-ef0a-1fc8063e9ed7@2ndquadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06523583-b9c5-1424-ef0a-1fc8063e9ed7@2ndquadrant.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2017-12-06 21:38:42 +0100, Tomas Vondra wrote: > It's one thing when the hash table takes longer to lookup something or longer aka "forever". > when it consumes a bit more memory. Say, ~2x more than needed, give or > take. I'm perfectly fine with that, particularly when it's a worst-case > evil data set like this one. I think the way to prevent that kind of attack is to add randomization. > FWIW I've constructed the data sets for two reasons - to convince myself > that my understanding of the simplehash code is correct, and to provide > a data set triggering the other growth condition in simplehash code. My > understanding is that if we stop growing the table after the load factor > drops below some threshold (as TL proposed earlier in this thread), it > should address both of these cases. Yea, I'm not adverse to adding a few stopgaps that break in a less annoying manner. WAll I'm saying is that I don't think we need to be super concerned about this specific way of breaking things. Greetings, Andres Freund