]> granicus.if.org Git - postgresql/commit
Fix worst memory leaks in tqueue.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Jul 2016 23:31:06 +0000 (19:31 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Jul 2016 23:31:06 +0000 (19:31 -0400)
commitaf33039317ddc4a0e38a02e2255c2bf453115fd2
tree6c01ea04e05aacc763f7be2cb63e800704e1eb17
parentbf4ae685ae6f37b7fe83336abacf44298431b2f0
Fix worst memory leaks in tqueue.c.

TupleQueueReaderNext() leaks like a sieve if it has to do any tuple
disassembly/reconstruction.  While we could try to clean up its allocations
piecemeal, it seems like a better idea just to insist that it should be run
in a short-lived memory context, so that any transient space goes away
automatically.  I chose to have nodeGather.c switch into its existing
per-tuple context before the call, rather than inventing a separate
context inside tqueue.c.

This is sufficient to stop all leakage in the simple case I exhibited
earlier today (see link below), but it does not deal with leaks induced
in more complex cases by tqueue.c's insistence on using TopMemoryContext
for data that it's not actually trying hard to keep track of.  That issue
is intertwined with another major source of inefficiency, namely failure
to cache lookup results across calls, so it seems best to deal with it
separately.

In passing, improve some comments, and modify gather_readnext's method for
deciding when it's visited all the readers so that it's more obviously
correct.  (I'm not actually convinced that the previous code *is*
correct in the case of a reader deletion; it certainly seems fragile.)

Discussion: <32763.1469821037@sss.pgh.pa.us>
src/backend/executor/nodeGather.c
src/backend/executor/tqueue.c
src/include/executor/tqueue.h