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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
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:54:42Z
Lists: pgsql-bugs
Greg Stark <stark@mit.edu> writes:
> 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.

By their very nature, hash algorithms have weak spots.  Pretending that
they do not, or that you can 100% remove them, is a fool's errand.

You could always "set enable_hashjoin = off", and deal with mergejoin's
weak spots instead; but that just requires a different data set to
expose its performance shortcomings ...

			regards, tom lane


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.