On Thu, 2005-03-24 at 15:52 -0500, Tom Lane wrote:
> Sven Willenberger <sven@dmv.com> writes:
> > 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 can confirm that my copy is not using mymalloc:
>
> $ perl -V | grep -i alloc
> usemymalloc=n, bincompat5005=undef
I went ahead and rebuilt perl using the system malloc instead, and what
I found was that on the function that started this whole topic, the
memory allocation went overboard and postgresql bailed with "out of
memory". Using the perl malloc, apparently postgres/plperl/libperl was
able to manage the memory load although it got "stuck" for the session.
Closing the session (psql) did end up freeing all the memory, at least
from top's perspective (since the process no longer existed) -- running
the query from the command line (psql -c "select function()") worked
over several iterations so I do believe that the memory does get freed
upon closing the connection. In fact we were able to run the query using
this method with 4 simulaneous connections and, although we went heavy
into swap , all four did complete. So the issue can be narrowed down to
a per-connection basis where the amount of memory needed by the function
would normally exceed available memory; the handler for this "overflow"
does something with the extra memory needed such that subsequent
invocations of the function during the same connection end up eventually
creating a malloc error.
(This is inconsistent with the behavior on the 8G opteron system ... but
I will reevaluate the issue I saw there and see if it is related to
something else).
Sven
