"Eric B.Ridge" <[EMAIL PROTECTED]> writes:
> Like I said, everything
> usually works without problems, but from time to time it crashes.
If you rebuild with --enable-cassert, does the crash get more
reproducible? (Personally I would never consider developing any
backend C code without that turned on.) It sounds like a use-of-
already-freed-memory bug, and if so --enable-cassert will help you
find it by clobbering memory blocks immediately during pfree.
> Below is the basic outline of my code.
I think you've forgotten that SPI_connect() and SPI_finish change
memory contexts. The stuff you allocated in your startup step
goes away as soon as you SPI_finish, leaving dangling pointers that
SRF_RETURN_DONE tries to clean up.
I'm also pretty uncomfortable with the fact that you're returning out
of your function while still connected to SPI. That would certainly
cause problems for anything else trying to use SPI in the same query.
You would probably be better off using the return-a-tuplestore mechanism
that plpgsql uses for set-valued results. That way you could connect
to SPI, issue your query, push the tuples into the tuplestore,
disconnect from SPI, and be done with only one pass through the
function. This would be a tad inefficient with a huge number of tuples
of course ... but you could convert the operation to use a SPI cursor
and thereby avoid duplicate storage of the tuples.
We didn't have tuplestores at the time the SPI API was designed. I
wonder whether we shouldn't extend SPI to have an option to return
tuples into a caller-provided tuplestore, instead of a SPI_tuptable.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
