Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tom Lane <tgl <at> sss.pgh.pa.us>
Subject: Re: Nasty problem in hash indexes
Newsgroups: gmane.comp.db.postgresql.devel.general
Date: Thursday 28th August 2003 21:37:39 UTC (over 14 years ago)
"scott.marlowe"  writes:
> If I'm reading this right, this bug means you could do:
> select * from table where field in (1,2,3,4)
> where you should get say 100 rows, and you might not get all 100 rows?

Yes, if you were concurrently inserting into the same table.  The given
example involved UPDATEs, not a SELECT.  Probably INSERT/SELECT could
see the same kind of failure.

I'm not sure whether a failure could occur across two backends (one
inserting and one selecting).  The page-level locking might prevent
that.  Or perhaps not.  If it could happen, of course the problem is
vastly more dangerous than if it can't.

> If so, then how many other bugs are lurking in the hash index code
> waiting to bite?

 Who's to say?  We've found bugs in the btree logic recently,
too.  But I have lots more confidence in btree.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
 
CD: 4ms