Fix memory leak in repeated GIN index searches.
commitab4ff2889d0bccc32467e681546aabdb87de4958
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 13 Mar 2016 20:44:10 +0000 (13 16:44 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 13 Mar 2016 20:44:31 +0000 (13 16:44 -0400)
tree3f4ced3b3f98d60ed7d25fb012ab7cda9bbe1d6b
parent96adb14d931e442e0a96f418d483fc896506146f
Fix memory leak in repeated GIN index searches.

Commit d88976cfa1302e8d removed this code from ginFreeScanKeys():
- if (entry->list)
- pfree(entry->list);
evidently in the belief that that ItemPointer array is allocated in the
keyCtx and so would be reclaimed by the following MemoryContextReset.
Unfortunately, it isn't and it won't.  It'd likely be a good idea for
that to become so, but as a simple and back-patchable fix in the
meantime, restore this code to ginFreeScanKeys().

Also, add a similar pfree to where startScanEntry() is about to zero out
entry->list.  I am not sure if there are any code paths where this
change prevents a leak today, but it seems like cheap future-proofing.

In passing, make the initial allocation of so->entries[] use palloc
not palloc0.  The code doesn't depend on unused entries being zero;
if it did, the array-enlargement code in ginFillScanEntry() would be
wrong.  So using palloc0 initially can only serve to confuse readers
about what the invariant is.

Per report from Felipe de Jesús Molina Bravo, via Jaime Casanova in
<CAJGNTeMR1ndMU2Thpr8GPDUfiHTV7idELJRFusA5UXUGY1y-eA@mail.gmail.com>
src/backend/access/gin/ginget.c
src/backend/access/gin/ginscan.c