Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
От | Kevin Grittner |
---|---|
Тема | Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows |
Дата | |
Msg-id | 1636574872.4282688.1439931243201.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | 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
Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows |
Список | 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 по дате отправления: