GiST buffering build, bug in levelStep calculation

I just noticed a little bug in the way the levelStep parameter is
calculated when we switch to buffering build:

set client_min_messages='debug2';

This works:

postgres=# set maintenance_work_mem='1GB';
SET
postgres=# create index i_gisttest on gisttest using gist (t collate
"C") WITH (fillfactor=10);
DEBUG: building index "i_gisttest" on table "gisttest"
DEBUG: switched to buffered GiST build; level step = 2, pagesPerBuffer
= 232

But with higher maintenance_work_mem, it fails to switch to buffering mode:

postgres=# set maintenance_work_mem='2GB';
SET
postgres=# create index i_gisttest on gisttest using gist (t collate
"C") WITH (fillfactor=10);
DEBUG: building index "i_gisttest" on table "gisttest"
DEBUG: failed to switch to buffered GiST build

This is because of this rather complex calculation here:

> while (
> /* subtree must fit in cache (with safety factor of 4) */
> (1 - pow(avgIndexTuplesPerPage, (double) (levelStep + 1))) / (1 - avgIndexTuplesPerPage) < effective_cache_size / 4
> &&
> /* each node in the lowest level of a subtree has one page in memory */
> (pow(maxIndexTuplesPerPage, (double) levelStep) < (maintenance_work_mem * 1024) / BLCKSZ)
> )

What happens here is that the calculation of (maintenance_work_mem *
1024) / BLCKSZ overflows the 32 bit signed integer type used there, if
maintenance_work_mem >= 2GB. I think we should be doing all these
calculations in double.

I'll go fix that..

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com