Sven Willenberger <sven@dmv.com> writes:
> On Thu, 2005-03-24 at 11:34 -0500, Tom Lane wrote:
>> The first thing to figure out is whether the leak is inside Perl or in
>> Postgres proper. If I were trying to do this I'd run the function a
>> couple times, then attach to the (idle) backend with gdb and do
>> call MemoryContextStats(TopMemoryContext)
> Not sure entirely how to interpret the results ... a cursory examination
> shows 516096 total in cachememory but I don't know if that reflects the
> state of "unfreed" memory (or perhaps the 354728 used is unfreed?):
That looks like the normal steady-state condition. The leak must be
inside Perl then.
[ thinks for a bit... ] Actually it seems possible that there's a
problem with poor interaction between Postgres and Perl. During the SPI
query they will both be making pretty substantial memory demands, and it
could be that the underlying malloc library isn't coping gracefully and
is ending up with very fragmented memory. That could result in
out-of-memory problems when in fact neither package is leaking anything
per se.
What you probably ought to do next is build Postgres with a debugging
malloc library to learn more about who's eating up what. I am not sure
whether libperl will automatically use the malloc attached to the main
executable or whether you need to whack it around too. (Come to think
of it, doesn't Perl normally use its very own private malloc? Maybe
there's an issue right there ...)
regards, tom lane