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() shouldn't return any already-dropped entries.
The hash_seq_search keeps track of what element that it should return
next when it peruses a bucket. Removing that element from the table
won't change anything since the HASH_SEQ_STATUS remains unaffected. It
still holds onto that element and hence, will return it on next iteration.
This should be considered a bug I think.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
