Joe Conway <mail@xxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
|
