From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Per-tuple memory leak in 9.0 |
Date: | 2010-08-18 20:52:46 |
Message-ID: | 12442.1282164766@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> The problem is that the trigger code assumes that anything it
> allocates in the per-tuple memory context will be freed per-tuple
> processed, which used to be the case because the loop in ExecutePlan()
> calls ResetPerTupleExprContext() once each time round the loop, and
> that used to correspond to once per tuple.
> However, with the refactoring of that code out to nodeModifyTable.c,
> this is no longer the case because the ModifyTable node processes all
> the tuples from the subquery before returning, so I guess that the
> loop in ExecModifyTable() needs to call ResetPerTupleExprContext()
> each time round.
Hmmm ... it seems a bit unclean to be resetting the output-tuple
exprcontext at a level below the top of the plan. I agree that that's
probably the sanest fix at the moment, but I fear we may need to revisit
this in connection with writable CTEs. We might need a separate output
tuple context for each ModifyTable node, or something like that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-18 22:02:58 | Re: BUG #5624: Getting error while taking the backup of database from remote machine |
Previous Message | Dean Rasheed | 2010-08-18 17:47:45 | Fwd: Per-tuple memory leak in 9.0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-08-18 20:57:13 | Re: Return of the Solaris vacuum polling problem -- anyone remember this? |
Previous Message | Robert Haas | 2010-08-18 20:40:20 | CommitFest 2009-07: Yay, Kevin! Thanks, reviewers! |