Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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: plperl_return_next_leak-2.patch
Description: text/x-patch (12.3 KB)

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group