Re: Nasty problem in hash indexes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Nasty problem in hash indexes
Дата
Msg-id 23630.1062106659@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Nasty problem in hash indexes  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: Nasty problem in hash indexes  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
"scott.marlowe" <scott.marlowe@ihs.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sean Chittenden
Дата:
Сообщение: [seanc@FreeBSD.org: Re: Performance tests I did with FreeBSD, Linux and PostgreSQL]
Следующее
От: Thomas Schoebel-Theuer
Дата:
Сообщение: Obscure: correctness of lock manager???