Am Sun, 17 Feb 2008 14:28:18 -0500
schrieb Tom Lane <tgl@xxxxxxxxxxxxx>:
> Stefan Niantschur <sniantschur@xxxxxx> writes:
> > Am Sun, 17 Feb 2008 09:17:08 -0500
> > schrieb Tom Lane <tgl@xxxxxxxxxxxxx>:
> >> Hardly surprising when you're printing the string into a fixed-size
> >> 8K buffer. The buffer overflow is smashing the stack, in particular
> >> the function's return address.
>
> > Yes, I know, but the backend does not allow for a bigger buffer.
> > Trying to use a 80K (char[81920])buffer did not work and returns:
>
> So you've got some other bug in code you didn't show us. It's highly
> unlikely that you wouldn't be able to allocate an 80K buffer.
> (Whether that's big enough for your data even yet is a separate
> question.)
>
> What I was wondering was why you even bothered with the char[] buffer,
> when it looked like the actually useful return value was being
> accumulated in an expansible StringInfo buffer.
>
> regards, tom lane
>
Hi all,
now after some days of intensive brainwork I could solve the problem
with a slight change in the code. It turned out that palloc() did not
reliably work for my purpose.
So before calling SPI_finish() I am doing the following:
text *out = (text *) SPI_palloc(strlen(cres) + VARHDRSZ);
memcpy(VARDATA(out), cres, strlen(cres));
VARATT_SIZEP(out) = strlen(cres) + VARHDRSZ;
SPI_finish();
which allocates the needed memory in the upper execution context. This
allows for passing the really long string back to the select statement
without crashing the database.
If there are any better proceedings, please let me know.
Best Regards,
Stefan
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
