Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Todd A. Cook <tcook@blackducksoftware.com>
From: "Todd A. Cook" <tcook@blackducksoftware.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2017-12-05T22:33:25Z
Lists: pgsql-bugs
Attachments
- reproducer_2.pgsql (text/plain)
On 12/05/17 17:01, Tomas Vondra wrote: > > > On 12/05/2017 10:23 PM, Todd A. Cook wrote: >> On 11/27/17 23:03, Tom Lane wrote: >>> Thomas Munro <thomas.munro@enterprisedb.com> writes: >>>> When SH_INSERT tries to insert that final extra value, insertdist >>>> keeps exceeding SH_GROW_MAX_DIB (25) no matter how many times we >>>> double the size (at least until my computer gives up, somewhere around >>>> 11 doublings and 75GB of virtual memory). If you set SH_GROW_MAX_DIB >>>> to 26 then it succeeds, but I guess some other attack could be crafted >>>> for that. What is the theory behind this parameter? >>> >>> You beat me to it --- after looking at simplehash.h I'd guessed that >>> either the SH_GROW_MAX_DIB or SH_GROW_MAX_MOVE code path was causing >>> an infinite loop, but I'd not gotten to determining which one yet. >>> >>> I'd ask what's the theory behind SH_GROW_MAX_MOVE, as well. Neither >>> of them are obviously loop-proof. >>> >>> Note that the sample data has a lot of collisions: >>> >>> regression=# select hashint8(val), count(*) from reproducer group by 1 >>> order by 2 desc; >>> hashint8 | count >>> -------------+------- >>> 441526644 | 2337 >>> -1117776826 | 1221 >>> -1202007016 | 935 >>> -2068831050 | 620 >>> 1156644653 | 538 >>> 553783815 | 510 >>> 259780770 | 444 >>> 371047036 | 394 >>> 915722575 | 359 >>> ... etc etc ... >>> >>> It's evidently more complicated than just that the code fails with >>> more than SH_GROW_MAX_DIB duplicate hashcodes, but I suspect not >>> by a lot. There needs to be a safety valve that prevents letting >>> the hash fill factor approach zero, which is what's happening in >>> this test case. >> >> FWIW, I can also reproduce the infinite loop with 167834 unique values. >> > > Unique values or unique *hash* values? Unique values. > Can you share the data, so that whoever fixes the bug can verify it also > fixes your example? Sure. It's attached. -- todd
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