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

Tom Lane wrote:
> Patch committed.

Given the change to SRF memory management, is the following still
necessary (or possibly even incorrect)?

in funcapi.c:
per_MultiFuncCall(PG_FUNCTION_ARGS)
{
FuncCallContext *retval = (FuncCallContext *)
fcinfo->flinfo->fn_extra;

/* make sure we start with a fresh slot */
if(retval->slot != NULL)
ExecClearTuple(retval->slot);

return retval;
}

All but one of the SRFs I've tried don't seem to care, but I have one
that is getting an assertion:

0x42029331 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x42029331 in kill () from /lib/i686/libc.so.6
#1 0x4202911a in raise () from /lib/i686/libc.so.6
#2 0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3 0x08179ab9 in ExceptionalCondition () at assert.c:48
#4 0x0818416f in pfree (pointer=0x7f7f7f7f) at mcxt.c:470
#5 0x0806bd32 in heap_freetuple (htup=0x832bb80) at heaptuple.c:736
#6 0x080e47df in ExecClearTuple (slot=0x832b2cc) at execTuples.c:406
#7 0x0817cf49 in per_MultiFuncCall (fcinfo=0xbfffe8e0) at funcapi.c:88
#8 0x40017273 in dblink_get_pkey (fcinfo=0xbfffe8e0) at dblink.c:911

Not quite sure why yet, but I'm thinking the ExecClearTuple() is no
longer needed/desired anyway.

Joe