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

Joe Conway <mail(at)joeconway(dot)com> writes:
> I have found the smoking gun, however. I had changed this function from
> returning setof text, to returning setof
> two_column_named_composite_type. *However*. I had not dropped and
> recreated the function with the proper declaration. Once I redeclared
> the function properly, the coredump went away, even with current
> per_MultiFuncCall() code.

Ah. I think the changes I just committed would have helped:
nodeFunctionscan.c now runs a tupledesc_mismatch() check regardless of
whether it thinks the function returns RECORD or not.

>> 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.

> OK. I'll make that change and leave ExecClearTuple() in
> per_MultiFuncCall(). Sound like a plan?

First let's see if we can figure out why the code is failing to fail
as it stands. The fact that it's not dumping core says there's
something we don't understand yet ...

regards, tom lane