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 the AcCommitPortals
> iteration continues, it sometimes encounter a deleted portal and elogs
> with an error stating "trying to delete portal name that does not exist".
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() shouldn't return any already-dropped entries.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
