Re: SRF's + SPI
От | Eric B.Ridge |
---|---|
Тема | Re: SRF's + SPI |
Дата | |
Msg-id | ff26db683bac193e7fb83c5e058700d6@tcdi.com обсуждение исходный текст |
Ответ на | Re: SRF's + SPI (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SRF's + SPI
|
Список | pgsql-hackers |
On Apr 1, 2005, at 3:55 PM, Tom Lane wrote: > "Eric B.Ridge" <ebr@tcdi.com> 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? Indeed. Every time. This is now the default for my development environment. > 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. Ditto. I knew this while writing the code but didn't see any other way to handle it. 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)? I need to look into what plpgsql does with the tuplestore business but I suppose it knows how to spill to disk and such. In the end, that's what I'd want, but I think it'll take me more than an hour to write that code. Thanks for your time and help. eric
В списке pgsql-hackers по дате отправления: