plperl: return_next memory leak

From: Neil Conway <neilc(at)samurai(dot)com>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Theo Schlossnagle <jesus(at)omniti(dot)com>
Subject: plperl: return_next memory leak
Date: 2006-01-26 03:13:12
Message-ID: 1138245192.8826.17.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Per a bug report from Theo Schlossnagle, plperl_return_next() leaks
memory in the executor's per-query memory context. It also inefficient:
it invokes get_call_result_type() and TupleDescGetAttInMetadata() for
every call to return_next, rather than invoking them once (per PL/Perl
function call) and memoizing the result.

This patch makes the following changes:

- refactor the code to include all the "per PL/Perl function call" data
inside a single struct, "current_call_data". This means we don't need to
save and restore N pointers for every recursive call into PL/Perl, we
can just save and restore one.

- lookup the return type metadata needed by plperl_return_next() once,
and then stash it in "current_call_data", so avoid doing the lookup for
every call to return_next.

- create a temporary memory context in which to evaluate the return
type's input functions. This memory context is reset for each call to
return_next.

The patch appears to fix the memory leak, and substantially improves the
performance of return_next (~140 ms vs. ~90 ms, in my simple trivial
test -- perhaps less of an improvement for more realistic functions).
The patch isn't minimally invasive -- I was thinking about developing a
more limited patch for REL8_1_STABLE, but I'm not sure if it is worth
the trouble.

Barring any objections, I'll apply this patch to HEAD and possibly
REL8_1_STABLE tomorrow.

-Neil

Attachment Content-Type Size
plperl_return_next_leak-2.patch text/x-patch 12.3 KB

Browse pgsql-patches by date

  From Date Subject
Next Message ITAGAKI Takahiro 2006-01-26 04:08:55 Re: Fix overflow of bgwriter's request queue
Previous Message Tom Lane 2006-01-26 02:37:06 Re: [HACKERS] CIDR/INET improvements