On Tue, May 13, 2008 at 8:19 AM, Josh Tolley <eggyknap@[EMAIL PROTECTED]
> wrote:
> On Tue, May 13, 2008 at 8:01 AM, Tom Lane <tgl@[EMAIL PROTECTED]
> wrote:
> > Martijn van Oosterhout <kleptog@[EMAIL PROTECTED]
> 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'll give this a shot as soon as I can... many thanks
>
>
> > 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.
>
> I'll check... that's definitely not unlikely. Again, thanks.
>
> - Josh
>
Proper (I hope) use of SPI_palloc() took care of this. And yes, the
8.2.x version I was using without problem was compiled without
enable-cassert. Once again, thanks.
- Josh / eggyknap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
