On 05/09/2012 05:06 PM, Joe Conway wrote:
> OK, new script. This more faithfully represents the real life scenario,
> and reproduces the issue on HEAD with out-of-the-box config settings,
> versus 8.1 which completes the query having never exceeded a very modest
> memory usage:
>
> ---------------
> On pg 8.1 with out of the box config:
> VIRT RES SHR
> 199m 11m 3032
> ---------------
> On pg head with out of the box config:
> VIRT RES SHR
> 1671m 1.5g 16m
> ---------------
The attached one-liner seems to plug up the majority (although not quite
all) of the leakage.
do_convert_tuple() is allocating a new tuple for every row in the loop
and exec_stmt_return_next() is leaking it.
The query now finishes successfully. On pg head with attached patch and
out of the box config:
VIRT RES SHR
196m 35m 31m
This look sane/correct?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index de1aece..24346c2 100644
*** a/src/pl/plpgsql/src/pl_exec.c
--- b/src/pl/plpgsql/src/pl_exec.c
*************** exec_stmt_return_next(PLpgSQL_execstate
*** 2469,2474 ****
--- 2469,2475 ----
{
tuple = do_convert_tuple(tuple, tupmap);
free_conversion_map(tupmap);
+ free_tuple = true;
}
}
break;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
