]> granicus.if.org Git - postgresql/commit
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks
authorNeil Conway <neilc@samurai.com>
Sat, 28 Jan 2006 03:28:15 +0000 (03:28 +0000)
committerNeil Conway <neilc@samurai.com>
Sat, 28 Jan 2006 03:28:15 +0000 (03:28 +0000)
commitebdefb93b2a57b0f717883a5f65149eb9af55dca
tree2c0c72ea776e16c7bdf40027497b5774504387c6
parentcab99ec300e45863464d964371ae88217cc0e5c4
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 as to 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 reduces
the overhead imposed by return_next.
src/pl/plperl/plperl.c