Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Date
Msg-id 1636574872.4282688.1439931243201.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Responses Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:

>         long        lbuckets;

>         lbuckets = 1 << my_log2(hash_table_bytes / bucket_size);

>     Assert(nbuckets > 0);

> In my case, the hash_table_bytes was 101017630802, and bucket_size was 48.
> So, my_log2(hash_table_bytes / bucket_size) = 31, then lbuckets will have
> negative number because both "1" and my_log2() is int32.
> So, Min(lbuckets, max_pointers) chooses 0x80000000, then it was set on
> the nbuckets and triggers the Assert().

> Attached patch fixes the problem.

So you changed the literal of 1 to 1U, but doesn't that just double
the threshold for failure?  Wouldn't 1L (to match the definition of
lbuckets) be better?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: WIP: SCRAM authentication
Next
From: Marko Tiikkaja
Date:
Subject: Re: Add support for RADIUS passwords longer than 16 octets