From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Memory leak in gingetbitmap |
Date: | 2015-01-29 16:09:31 |
Message-ID: | 54CA5B3B.3060906@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-01-29 16:10:09 | Re: pg_dump with both --serializable-deferrable and -j |
Previous Message | Robert Haas | 2015-01-29 16:08:55 | Re: TABLESAMPLE patch |