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 whole 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

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.


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-2015 The PostgreSQL Global Development Group