Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop
От | Andres Freund |
---|---|
Тема | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop |
Дата | |
Msg-id | 20180129231258.atscgnc5qkt3lra5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 2018-01-29 17:54:42 -0500, Tom Lane wrote: > 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. Having edge case weaknesses and having remotely triggerable weaknesses aren't the same. And the cost for preventing such misuse is a immeasurable runtime difference and returning queries that don't specify an order and don't have a "natural" order with a changing order. That's not particularly high. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: