Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "Todd A. Cook" <tcook@blackducksoftware.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2018-01-29T22:16:24Z
Lists: pgsql-bugs
On 29 January 2018 at 19:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One other point here is that it's not really clear to me what a randomly
> varying IV is supposed to accomplish.  Surely we're not intending that
> it prevents somebody from crafting a data set that causes bad hash
> performance.

I actually think that is a real live issue that we will be forced to
deal with one day. And I think that day is coming soon.

It's not hard to imagine a user of a web site intentionally naming
their objects such that they all hash to the same value. Probably most
systems the worst case is a query that takes a few seconds or even
tens of seconds but if you get lucky you could run a server out of
memory.

I'm actually thinking we should replace all the hashes with
https://en.wikipedia.org/wiki/SipHash with a randomly generated key.

-- 
greg


Commits

  1. Improve bit perturbation in TupleHashTableHash.

  2. Prevent growth of simplehash tables when they're "too empty".

  3. Add stack-overflow guards in set-operation planning.