"scott.marlowe" <[EMAIL PROTECTED]> 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?
<shrug> 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
