Tom Lane wrote:
"Thomas" <[EMAIL PROTECTED]> writes:This report origins from the hackers thread "SPI_finish and RegisterExprContextCallback" where you indicated that my report did not properly describe a problem. Since my report was correct and since you stated that "hash_seq_search() shouldn't return any already-dropped entries." I was led me to believe that it was *not* designed to do that.
The hash_seq_search keeps track of what element that it should return next
in a HASH_SEQ_STATUS struct when it peruses a bucket. Removing that element
from the table won't change anything since the struct remains unaffected. It
still holds onto that element and hence, will return it on next iteration.
This isn't a bug; it's the designed way for it to work. It's up to
callers to avoid causing a problem.
Anyway, the AtCommit_Portals doesn't avoid this problem and the end result for me is the same regardless of where the error is. I can't drop portals using a ExprContextCallback and I'd like to know the best way to fix it. I can contribute a patch but I want you to decide what needs to be fixed.
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
