Re: Error during hash index scans can cause postgres halt!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "ykhuang" <hyk(at)ruc(dot)edu(dot)cn>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Error during hash index scans can cause postgres halt!
Date: 2008-03-07 14:13:09
Message-ID: 12594.1204899189@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> 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 :-(

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2008-03-07 15:25:08 Re: Error during hash index scans can cause postgres halt!
Previous Message Tom Lane 2008-03-07 13:58:08 Re: BUG #4019: Comparison of user defined domain doesn't work