Dean Rasheed <dean.a.rash...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
