While looking at the segfault that Olaf Gawenda reported (bug #12694), I
realized that the GIN fast scan patch introduced a small memory leak to
re-scanning a GIN index. In a nutshell, freeScanKeys() needs to pfree()
the two new arrays, requiredEntries and additionalEntries.
After fixing that, I'm still seeing a small leak. I found that the
queryCategories field also needs to be free'd, but it still leaks even
after fixing that.
I think we need a more whole-sale approach. I'm thinking of adding a new
memory context to contain everything related to the scan keys, which can
then be destroyed in whole.
We haven't heard any complaints about this from users, but I think this
deserves to be fixed. Perhaps not worth back-patching however.
PS. Here's what I'm using to test this:
create extension btree_gin;
create table a (t text);
create table b (t text);
insert into b values ('foo'), ('bar');
insert into a select 'x'||g from generate_series(1, 2000000) g;
create index i_b On b using gin (t) ;
set enable_hashjoin=off;
set enable_material=off;
set enable_seqscan=off;
set enable_mergejoin=off;
set enable_indexscan=off;
select * from a, b where a.t = b.t;
It doesn't leak if the index is a regular b-tree index.
- Heikki