Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Newman <dtnewman(at)gmail(dot)com>, danielnewman(at)umich(dot)edu, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Date: 2016-07-16 20:10:15
Message-ID: CAM3SWZQ2ikFHTTdbWcvrdBLdtDycY-0K4-XQa3wMpwA4D+181A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Jul 16, 2016 at 1:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I suppose that the assertion made the new hash index searches redundant.
>
> [ thinks about it a bit more... ] Actually, maybe it doesn't. The thing
> that made 9f03ca915196dfc8 really nasty is that it built an index that was
> actually corrupt, with incorrect hash codes stored for entries. I think
> your assertion would probably have caught that, but only accidentally,
> because the problem had little to do with whether the sort satisfied its
> charter. Maybe we should stick at least one simple test query in there
> before we drop the index again.

That's what I was thinking, but wasn't sure offhand which way it would
happen. Couldn't hurt much to just add one more test.

It is pretty awkward how the hash index searches are in
hash_index.sql, which must coordinate with create_index.sql, but I
didn't want to go against the grain and just put it all in one place.
Maybe I should have.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2016-07-16 20:32:30 Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
Previous Message Tom Lane 2016-07-16 20:04:36 Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column