Hah, got it. The reason the leak only manifests on 32-bit is that it
only manifests if int8 is a pass-by-reference datatype. The new API
for amgetbitmap causes a query-lifespan leak of one palloc(sizeof(int8))
per bitmap index scan. The distinguishing feature of your query seems
to be just that it does enough repeated bitmapscans to notice ...
The attached patch cures the leak for me, but I find it a tad ugly.
I'm tempted to think that it would be better if we changed the call
signature for amgetbitmap so that it returned the count through an
"int64 *" output parameter. Thoughts anyone?
regards, tom lane
Index: src/backend/access/index/indexam.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/index/indexam.c,v
retrieving revision 1.110
diff -c -r1.110 indexam.c
*** src/backend/access/index/indexam.c 11 Sep 2008 14:01:09 -0000 1.110
--- src/backend/access/index/indexam.c 9 Oct 2008 22:47:54 -0000
***************
*** 655,660 ****
--- 655,661 ----
{
FmgrInfo *procedure;
int64 ntids;
+ Datum d;
SCAN_CHECKS;
GET_SCAN_PROCEDURE(amgetbitmap);
***************
*** 665,673 ****
/*
* have the am's getbitmap proc do all the work.
*/
! ntids = DatumGetInt64(FunctionCall2(procedure,
!
PointerGetDatum(scan),
!
PointerGetDatum(bitmap)));
pgstat_count_index_tuples(scan->indexRelation, ntids);
--- 666,680 ----
/*
* have the am's getbitmap proc do all the work.
*/
! d = FunctionCall2(procedure,
! PointerGetDatum(scan),
! PointerGetDatum(bitmap));
!
! ntids = DatumGetInt64(d);
!
! #ifndef USE_FLOAT8_BYVAL
! pfree(DatumGetPointer(d));
! #endif
pgstat_count_index_tuples(scan->indexRelation, ntids);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
