Jeff Janes <jeff.ja...@gmail.com> writes:
> I bisected it down to:
> d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf is the first bad commit
> commit d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf
> Author: Heikki Linnakangas <heikki.linnakan...@iki.fi>
> Date: Wed Feb 4 17:40:25 2015 +0200
> Use a separate memory context for GIN scan keys.
Yeah, I had come to the same conclusion. The leak comes from removing
this bit from ginFreeScanKeys():
- if (entry->list)
- pfree(entry->list);
Heikki evidently supposed that entry->list would be allocated in
the so->keyCtx, but as things stand, it is not: it gets allocated
in the query-lifespan context, so this change causes a leak of
potentially several kB per ginrescan cycle. And the test query
does about 120000 of those.
I think it would likely be a good thing to fix things so that that
assumption actually holds, but I'm not familiar enough with this code
to decide what's the best way to do that. (Basically, the question is
"how much of startScanEntry() ought to run with keyCtx as current memory
context?") As a short-term fix I plan to reinstall the above-cited pfree.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
