Re: PostgreSQL BugTool Submission

Unprivileged user <nobody@hub.org> 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