From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Eric B(dot) Ridge" <ebr(at)tcdi(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SRF's + SPI |
Date: | 2005-04-01 21:56:44 |
Message-ID: | 28949.1112392604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Eric B. Ridge" <ebr(at)tcdi(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Tillotson | 2005-04-02 00:41:54 | Re: Debugging deadlocks |
Previous Message | Eric B.Ridge | 2005-04-01 21:29:31 | Re: SRF's + SPI |