From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Josh Tolley <eggyknap(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem returning strings with pgsql 8.3.x |
Date: | 2008-05-13 14:01:52 |
Message-ID: | 24389.1210687312@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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 executor memory 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-13 14:12:44 | Re: no privileges were granted |
Previous Message | ludwig | 2008-05-13 13:56:38 | Re: Substring Problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-13 14:10:16 | Re: Fairly serious bug induced by latest guc enum changes |
Previous Message | Magnus Hagander | 2008-05-13 13:54:21 | Re: Fairly serious bug induced by latest guc enum changes |