]> granicus.if.org Git - postgresql/commit
Fix memory leak in repeated GIN index searches.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 13 Mar 2016 20:44:10 +0000 (16:44 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 13 Mar 2016 20:44:10 +0000 (16:44 -0400)
commitaa9c4e71ceccf239a268b0b6611a9260d0f94a74
treea558a2f563a2c4c97d8b6751ec971724593f95a9
parenta7915f114aad83c93548dffe6c947e7f441fc175
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