Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)

Joe Conway <mail(at)joeconway(dot)com> writes:
> As you said, if the next ExecStoreTuple will try to do an
> ExecClearTuple(), ISTM that it should be removed from
> per_MultiFuncCall()/SRF_PERCALL_SETUP(). Or am I crazy?

Actually ... on second thought ...

I bet the real issue here is that we have a long-lived TupleTableSlot
pointing at a short-lived tuple. (I assume you're just forming the
tuple in the function's working context, no?)

When ExecClearTuple is called on the next time through, it tries to
pfree a tuple that has already been recycled along with the rest of
the short-term context. Result: coredump.

However, if that were the story then *none* of the SRFs returning
tuple should work, and they do. So I'm still confused.

But I suspect that what we want to do is take management of the tuples
away from the Slot: pass should_free = FALSE to ExecStoreTuple in the
TupleGetDatum macro. The ClearTuple call *is* appropriate when you do
that, because it will reset the Slot to empty rather than leaving it
containing a dangling pointer to a long-since-freed tuple.

regards, tom lane