Re: BUG #6698: sub-query with join producing out of memory in where clause

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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