Re: Nasty problem in hash indexes

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: Nasty problem in hash indexes
Дата
Msg-id Pine.LNX.4.33.0308282222470.6064-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: Nasty problem in hash indexes  (Neil Conway <neilc@samurai.com>)
Ответы Re: Nasty problem in hash indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 28 Aug 2003, Neil Conway wrote:

> On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
> > > 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.
> 
> I'd rather print a loud warning when a hash index is created, but keep
> the code in the tree, than just remove it entirely. That way, we'll
> avoid unnecessary bit-rot to some degree, and if someone feels that
> they absolutely positively need hash indexes, they will have some
> existing work to begin from.

Sorry, but if hash indexes really do present a possible race condition 
where you could get a short read WITH NO ERROR, then they should at least 
be commented out and if you create one USING HASH we should print a notice 
that we're actually creating a btree for you and hash has been deprecated 
at this point.

I can see leaving the code in as something to work on, but you shouldn't 
have to worry about whether or not your database is gonna have a short 
read without an error.

Postgresql's philosophy has always seemed to be correctness first, 
convenience and performance second.  I like that philosophy, compared to 
many other databases out there. 




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

Предыдущее
От: Bruce Badger
Дата:
Сообщение: Re: FE/BE Protocol - Specific version
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Nasty problem in hash indexes