Re: Nasty problem in hash indexes

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nasty problem in hash indexes
Date: 2003-08-29 04:28:21
Message-ID: Pine.LNX.4.33.0308282222470.6064-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-29 04:38:40 Re: Nasty problem in hash indexes
Previous Message Bruce Badger 2003-08-29 04:18:40 Re: FE/BE Protocol - Specific version