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

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 16:13:17
Message-ID: 16136.1204906397@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> 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?

The pfree() would touch the context control data, not just the
HashScanList struct itself.  Also on some platforms it's possible that
malloc would've returned the freed context to the system, resulting in
a segfault because we touch unmapped memory.  But I agree that it'd
be far more probable to see the problem with --enable-cassert.

> Want me to hack up a patch, or you going to just commit that yourself?

Already done, I didn't see your message till just now.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2008-03-07 19:51:15
Subject: Re: BUG #4019: Comparison of user defined domain doesn't work
Previous:From: Tom LaneDate: 2008-03-07 16:07:17
Subject: Re: Error during hash index scans can cause postgres halt!

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