Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: "Todd A. Cook" <tcook@blackducksoftware.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>,
PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2017-11-28T02:20:40Z
Lists: pgsql-bugs
On Tue, Nov 28, 2017 at 11:10 AM, Andres Freund <andres@anarazel.de> wrote: > On 2017-11-27 15:59:37 -0500, Todd A. Cook wrote: >> COPY reproducer (val) FROM stdin; >> 2976219712004784288 >> -6429122065899879392 >> -7471109962990387136 >> -7471109962990387136 >> -2895470491222113184 >> -4083509061952565472 >> 1019481548263425664 >> 4639248884787347648 >> -6999443831165647744 >> -4199917803455020480 >> -4110530183001439680 > > How are these values generated? They awfully look like hash values > (~same lenght, full numerical range)... 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? -- Thomas Munro http://www.enterprisedb.com
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