Re: Problem returning strings with pgsql 8.3.x - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem returning strings with pgsql 8.3.x
Date
Msg-id 24389.1210687312@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem returning strings with pgsql 8.3.x  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Problem returning strings with pgsql 8.3.x  ("Josh Tolley" <eggyknap@gmail.com>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Mon, May 12, 2008 at 11:23:17PM -0600, Josh Tolley wrote:
>> SPI_push();
>> retval =
>> InputFunctionCall(&flinfo, lolVarGetString(returnVal, true),
>> resultTypeIOParam, -1);
>> SPI_pop();

> Won't this cause the return value to be allocated inside a new memory
> block which gets freeds at the SPI_pop?

The SPI_pop in itself is harmless ... the problem is the SPI_finish
further down, which will release all simple palloc's done within the
SPI function context.  What he needs is something comparable to this bit
in plpgsql:
           /*            * If the function's return type isn't by value, copy the value            * into upper
executormemory context.            */           if (!fcinfo->isnull && !func->fn_retbyval)           {
Size       len;               void       *tmp;
 
               len = datumGetSize(estate.retval, false, func->fn_rettyplen);               tmp = SPI_palloc(len);
       memcpy(tmp, DatumGetPointer(estate.retval), len);               estate.retval = PointerGetDatum(tmp);
}

ie, push the data into something allocated with SPI_palloc().

I would bet large amounts of money that the problem is not "new in
8.3.0", either.  Perhaps Josh was not testing in an --enable-cassert
(CLOBBER_FREED_MEMORY) build before.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Fairly serious bug induced by latest guc enum changes
Next
From: Tom Lane
Date:
Subject: Re: Fairly serious bug induced by latest guc enum changes