Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: "Todd A. Cook" <tcook@blackducksoftware.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2017-12-06T20:46:16Z
Lists: pgsql-bugs
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
Commits
-
Improve bit perturbation in TupleHashTableHash.
- d18d4bca81f8 10.2 landed
- c068f87723ca 11.0 landed
-
Prevent growth of simplehash tables when they're "too empty".
- d1aac2998789 10.2 landed
- ab9f2c429d8f 11.0 landed
-
Add stack-overflow guards in set-operation planning.
- 1b2a3860d3ea 10.2 cited