From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | chifungfan(at)yahoo(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PostgreSQL BugTool Submission |
Date: | 2000-08-22 04:20:30 |
Message-ID: | 4497.966918030@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Unprivileged user <nobody(at)hub(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2000-08-22 07:41:29 | Re: to_char Bug... |
Previous Message | Arthur M. Kang | 2000-08-21 21:41:09 | to_char Bug... |