Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
I can reproduce this, with --enable-cassert. It crashes when aborting
the transaction, in ReleaseResources_hash. The HashScanList items are
allocated in ExecutorState memory context, but that context has already
been deleted by the time we get to ReleaseResources_hash.
Ouch. So this has been broken (by me, I think :-() since 8.0. Tells
you something about how many people use hash indexes :-(
Yeah. Also, this is very hard to trigger without --enable-cassert (or
just CLOBBER_FREED_MEMORY). It's extremely unlikely that something new
is allocated on the piece of memory that was used by an HashScanList
item, during AbortTransaction processing.
ykhuang, were you running an assertion-enabled build as well?
Another idea would be to allocate the HashScanList items in a
longer-lived memory context. The IndexScanDesc struct pointed to by the
HashScanList would still be in ExecutorState context, but that's all
right because we don't need to access it in ReleaseResources_hash.
That seems like a winner to me. We can rely on the resource owner
mechanism to free up individual HashScanList items, so there's no real
need to keep them in a short-lived context. I'm inclined to just drop
them into TopMemoryContext. We could make a hash-specific context but
I'm not convinced it's worth the extra code to do it.
Want me to hack up a patch, or you going to just commit that yourself?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
