Hi, Continuing on this:
Can someone please explain why we do not reset the expression context if an SRF is involved during execution? Once the current result from the SRF has been consumed, I would think that the ecxt_per_tuple_memory context should be reset. As its name suggests, it is supposed to a per tuple context and is not meant to be long-lived. To test this out I shifted the call to ResetExprContext to just before returning from the SRF inside ExecResult and I do not see the memleak at all. Patch attached with this mail. The SRF has its own long-lived "SRF multi-call context" anyways. And AIUI, SRFs return tuples one-by-one or do we materialize the same into a tuplestore in some cases? Regards, Nikhils On Wed, May 5, 2010 at 7:23 PM, Nikhil Sontakke <nikhil.sonta...@enterprisedb.com> wrote: > Hi, > > I saw this behavior with latest GIT head: > > create table xlarge(val numeric(19,0)); > insert into xlarge values(generate_series(1,5)); > > The above generate series will return an int8 which will then be > casted to numeric (via int8_to_numericvar) before being inserted into > the table. I observed that the ExprContext memory associated with > econtext->ecxt_per_tuple_memory is slowly bloating up till the end of > the insert operation. > > This becomes significant the moment we try to insert a significant > number of entries using this SRF. I can see the memory being consumed > by the PG backend slowly grow to a large percentage. > > I see that the executor (take ExecResult as an example) does not reset > the expression context early if an SRF is churning out tuples. What > could be a good way to fix this? > > Regards, > Nikhils > -- > http://www.enterprisedb.com > -- http://www.enterprisedb.com
diff --git a/src/backend/executor/nodeResult.c b/src/backend/executor/nodeResult.c index 94796d5..bddc632 100644 --- a/src/backend/executor/nodeResult.c +++ b/src/backend/executor/nodeResult.c @@ -100,7 +100,10 @@ ExecResult(ResultState *node) { resultSlot = ExecProject(node->ps.ps_ProjInfo, &isDone); if (isDone == ExprMultipleResult) + { + ResetExprContext(econtext); return resultSlot; + } /* Done with that source tuple... */ node->ps.ps_TupFromTlist = false; }
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers