Tom Lane wrote:
The comment for AtCommit_Portals points out that there are risks of this
sort, but I don't think you've described it properly. The
SPI_cursor_close operation is probably failing not succeeding, because
AtCommit_Portals will never find an already-deleted portal ---
hash_seq_search()
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> AtCommitPortals (portalmem.c) iterates over the entries in the
> PortalHashTable. This causes a chain of calls that sometimes reach an
> ExprContextCallback. If that callback issues a succesfull
> SPI_cursor_close some problems might lay ahead. As t
I found another piece of information that might be of interest. This is
related to nested calls and the ExprContextCallback but not related to
nested active cursors.
AtCommitPortals (portalmem.c) iterates over the entries in the
PortalHashTable. This causes a chain of calls that sometimes reac
Tom,
You're right, you can't just return from that inner function while
leaving its SPI connection open.
It might be interesting to redesign SPI around the notion of independent
"connection objects" rather than necessarily having a stack of 'em.
I made the same reflection looking at the SPI code
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> 1. I call a function that does an SPI_connect, SPI_prepare,
> SPI_cursor_open, and finally attempts to do an SPI_cursor_fetch.
> 2. Since the SQL statement I'm executing contains a call to function
> returning SETOF, and since that function in turn ac
Tom Lane wrote:
From where?
Minimum respect for the time of your fellow hackers would suggest
including a gdb traceback in questions like this.
My apologies. I'll do that next time. I was on a win32 system and the
gdb that comes with the MinGW environment just doesn't do it for me (if
anyone o
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> The callback is called OK but when it calls SPI_finish I get
> an illegal memory access signal.
>From where?
Minimum respect for the time of your fellow hackers would suggest
including a gdb traceback in questions like this.
I'd like to write a C-function that returns a SETOF a complex type. This
set is obtained from a query performed using an SPI cursor. I don't want
to build the complete set in memory so I tried the following.
1. During the SRF_IS_FIRSTCALL phase, I do an SPI_connect and I create
the cursor using
