| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Date: | 2018-01-29 22:16:24 |
| Message-ID: | CAM-w4HO4ur37XMqpYPardPa3rZiDVcSYfe62sPAfTGooDFk3WQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 29 January 2018 at 19:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-01-29 22:54:42 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Previous Message | Andres Freund | 2018-01-29 19:32:20 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |