"Eric B. Ridge" <ebr@tcdi.com> 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