On Thu, 2005-03-24 at 13:51 -0500, Tom Lane wrote: > Sven Willenberger <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly