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