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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq