Re: Nasty problem in hash indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nasty problem in hash indexes
Date: 2003-08-28 21:37:39
Message-ID: 23630.1062106659@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2003-08-28 21:44:26 Re: New array functions
Previous Message Carlos Guzman Alvarez 2003-08-28 21:35:32 PostgreSQL SSL Connections