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

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> Finally found time for this. Attached patch tests hash tuplesorts
> along the lines we discussed. It adds one new tuplesort operation,
> which does not spill to disk. It also asserts that hash values
> retrieved through the tuplesort interface are in fact in sorted order.
> I wanted to have something reliably trip when comparetup_index_hash()
> gives wrong answers, even when a corrupt final index is perhaps not a
> consequence of the underlying bug.

Pushed with some adjustments, mostly paranoia concerning integer overflows
in the calculation around maintenance_work_mem. I did not like the way
you'd set up the test case though: tenk1 is *very* heavily used in the
regression tests, and having an extra index on it that might capture query
plans for unrelated test cases doesn't seem like a good idea. Especially
not when you drop the index in the middle of a large group of parallel
tests, so that any capturing that did happen would be timing-sensitive.
So I just made the create_index test create and immediately drop the
index. We have other tests that are supposed to exercise searches of
hash indexes, anyway.

regards, tom lane