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.
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 |