Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> This test case can be further reduced into:
> explain analyze
> SELECT * FROM generate_series(1,100000) i
> WHERE (SELECT array(select repeat('a', 10000) || i) u1) is not null;
> We're leaking the array constructed on each row, in ExecSetParamPlan().
> At line 1000 in nodeSubplan.c, we create a new array and store it as the
> value of the PARAM_EXEC parameter. But it's never free'd. The old value
> of the parameter is simply overwritten.
> I'm not sure what the correct fix is. I suppose we could pfree() the old
> value before overwriting it, but I'm not sure if that's safe, or if
> there might still be references to the old value somewhere in the executor.
I think it should be safe to pfree the prior value at this point. If
you compare the code for scalar subplan results, a few lines above here,
pass-by-ref param values are references into node->curTuple which gets
summarily freed on the next cycle. So if anybody is keeping a pointer
around then it would already be failing for non-ARRAY cases, and we've
not seen any such reports. I think we can handle array results the same
way as curTuple, ie, keep a link in the node's state. (I thought first
about trying to pfree the prior contents of prm->value itself, but I'm
less sure that that is safe --- if memory serves, the same ParamExecData
slot can sometimes be used for multiple purposes.)
Will give it a try ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
