> It seems to me there are two things to fix here: indexscan ought to
> pfree everything it pallocs, and RelationBuildDesc ought to be warier
> about how much work gets done with CacheCxt as the active palloc
> context. (Even if indexscan didn't leak anything ordinarily, there's
> still the risk of elog(ERROR) causing an abort before the indexscan code
> gets to clean up.)
As far as cleaning up from an elog, my only idea would be to have a
global List that contains pointers that should be freed from any elog().
The cache code would lconc() any of its pointers onto the list, and an
elog() would check the list and free anything on there. The problem is
that many times the palloc's happen in non-cache functions, so the cache
code may not have access to the palloc address, and if we put it
everywhere, we are doing this for non-cache calls, which may be too much
overhead. We could also try clearing the cache on an elog() but that
seems extreme too.
ie, cache function calls a function that allocates memory then calls
another function that fails. The memory is in cache context, but the
cache function never saw a return from it's first call, so it couldn't
add it to the elog global free list.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026