On Thu, 2005-03-24 at 13:51 -0500, Tom Lane wrote:
> 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
>
Yes, on these systems, perl was build with -Dusemymalloc (and
concurrently -Ui_malloc) so there could very well be an issue with
malloc pools going awry. Doing a quick dig reveals that Linux tends to
build perl (by default) with the system malloc which may explain why
your script did not display this same behavior. I will try to rebuild
perl using system malloc and see how that affects things.
Sven