Unprivileged user <[EMAIL PROTECTED]> writes:
> The backend crash after seeing a message 'NOTICE: trying to delete
> portal name that does not exist' after using a cursor on a particular
> query (which'll be shown below).
Oooh, that's a nasty one! The problem is one of bogus memory management
for the hash table that's used by the hash join that the sub-select is
implemented with. As seen in 7.0.*, the problem is that the hash table
is stored in a separate "portal" which might be deleted before the
portal the CURSOR itself is kept in. (If so, the eventual delete of the
cursor finds itself referencing already-freed memory.) Current sources,
7.1-to-be, use a different memory management scheme but still exhibited
a genetically related bug.
I have fixed the problem in current sources but don't see any reasonably
simple/trustworthy way of fixing it in 7.0.*. What I'd suggest as a
short-term band-aid is picking a different cursor name. A little
experimentation should find a name that hashes before the name generated
internally for the hashtable portal --- that will ensure that shutdown
occurs in appropriate order. A kluge, I know :-(
Thanks for the excellent bug report ... I'm sure it was a pain nailing
down a reproducible example of this creepie-crawlie.
regards, tom lane
