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

From Kouhei Kaigai
Subject Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F801134B01@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (Kevin Grittner <kgrittn@ymail.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?
>
Ah, yes, it is my careless mistake.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Make HeapTupleSatisfiesMVCC more concurrent
Next
From: David Rowley
Date:
Subject: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows