Hello,
My colleague Adrien reported me a memory leak in GIN indexes while doing
some benchmark on several am.
Here is a test case to reproduce the issue:
CREATE TABLE test AS (
SELECT t
FROM generate_series(now(), now() + interval '10 day', '1 second')
AS d(t)
CROSS JOIN generate_series(1, 100) s
);
CREATE EXTENSON btree_gin;
CREATE INDEX ON test USING gin(t);
EXPLAIN ANALYZE SELECT * FROM test WHERE t >= now() and t < now() +
interval '10 day';
The last query will consume approximately 4GB of RAM (might need to
force index scan) in ExecutorState memory context.
I'm not at all familiar with GIN code, but naive attached patch seems to
fix the issue and not break anything. I can reproduce this issue up to 9.4.
Regards
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c
index b79ba1e..6108298 100644
--- a/src/backend/access/gin/ginget.c
+++ b/src/backend/access/gin/ginget.c
@@ -281,6 +281,7 @@ collectMatchBitmap(GinBtreeData *btree, GinBtreeStack
*stack,
ipd = ginReadTuple(btree->ginstate, scanEntry->attnum,
itup, &nipd);
tbm_add_tuples(scanEntry->matchBitmap, ipd, nipd,
false);
scanEntry->predictNumberResult += GinGetNPosting(itup);
+ pfree(ipd);
}
/*
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
