Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop
От | Stephen Frost |
---|---|
Тема | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop |
Дата | |
Msg-id | 20171206205750.GM4628@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
Andres, all, * Andres Freund (andres@anarazel.de) wrote: > On 2017-12-06 21:38:42 +0100, Tomas Vondra wrote: > > 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. I think I'm agreeing with Tomas here when I say that we shouldn't have a system that breaks in the "tries to allocate infinite memory" way when the load factor drops far below some reasonable threshold and that we *should* be concerned that we have this problem in the existing implementation. It's bad, and we should care about that and fix it. Running forever in a loop isn't great either, but at least you only expend at most one CPU to it and can go kill it, assuming we have an appropriate CHECK_FOR_INTERRUPTS() placement. Running the box out of memory can lead to other things *failing* (even entirely reasonable things!), not just being slower. That's an important difference. Thanks! Stephen
В списке pgsql-bugs по дате отправления: