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

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 (view raw or flat)
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

pgsql-hackers by date

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

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