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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown