Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL BugTool Submission

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-bugs by date

Next:From: Karel ZakDate: 2000-08-22 07:41:29
Subject: Re: to_char Bug...
Previous:From: Arthur M. KangDate: 2000-08-21 21:41:09
Subject: to_char Bug...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group