"Eric B. Ridge" <[EMAIL PROTECTED]> writes: > The tuplestore stuff sounds like the right solution, but in the > interests of providing a quick patch to my production environment does > it makes sense to make a copy of the SPI_tuptable during the first-call > of the SRF (allocated in the SRF's memory context of course)?
You could do that, but I don't believe there's any existing code that copies a whole SPI_tuptable, which means that pushing the tuples into a tuplestore would be about the same amount of new code. For a quick-patch solution it would probably suffice to NULL out those pointers you put in the SRF state immediately before you do SRF_RETURN_DONE. SPI is deleting the stuff fine, the problem is just the double free attempt from SRF_RETURN_DONE. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org