| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Date: | 2017-11-28 02:20:40 |
| Message-ID: | CAEepm=3SC9zYLKhvtZbsnwf9vEpi96WCGz1rdGLofuzBau=fqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Nov 28, 2017 at 11:10 AM, Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-11-28 04:03:03 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Previous Message | Michael Paquier | 2017-11-28 01:39:34 | Re: [BUGS] BUG #14866: The generated constraint in the typed table causes the server to crash |