From: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows |
Date: | 2015-08-18 23:56:47 |
Message-ID: | 9A28C8860F777E439AA12E8AEA7694F801134B01@BPXM15GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2015-08-19 00:00:13 | Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows |
Previous Message | Tom Lane | 2015-08-18 23:49:10 | Re: Make HeapTupleSatisfiesMVCC more concurrent |