Re: Potential memory leak in contrib/intarray's g_intbig_compress

I wrote:
> Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
>> My collegue Konstantin (cc-ed) noticed that the GiST code of intarray
>> may leak memory in certain index operations:

> Can you demonstrate an actual problem here, that is a query-lifespan leak?

> IMO, the coding rule in the GiST and GIN AMs is that the AM code is
> responsible for running all opclass-supplied functions in suitably
> short-lived memory contexts, so that leaks within those functions
> don't cause problems.

I tried adding "MemoryContextStats(CurrentMemoryContext);" at the top
of g_intbig_compress() and running the intarray regression tests
(which do reach the pfree in question). This confirmed that the
compress function is always called in the "GiST temporary context"
made by createTempGistContext. Also, the amount of memory reported as
consumed didn't seem to vary when I removed the pfree, which indicates
that we do manage to reset that context often enough that leakage here
doesn't matter. It's hard to make an exact comparison because of
GiST's habit of randomizing page-split decisions, so that the sequence
of calls to the compress function isn't identical from one run to the
next. But at least in the cases exercised by the regression tests,
we do not need that pfree --- and if you believe the comment for
createTempGistContext, it would be a GiST bug not an intarray bug
if we did.

I'll go remove the pfree. Perhaps there is a TODO item here to
improve the documentation about these memory management conventions.

regards, tom lane