Re: Preliminary notes about hash index concurrency (long)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> I've been looking at fixing the problem reported a few days ago whereby
>> a bucket split in a hash index messes up the state of concurrent scans
>> of the index, possibly causing some tuples to be missed by the scans.

> Seems you are adding locking similar to what we already do in btree.

Not adding locking --- hash already has locking. The problem is the
locking is wrong (both inadequate and deadlock prone :-().

> I know we have two sets of hash codes -- the one used for hash indexes,
> and another used for hash joins and now aggregates and subqueries.

There's only one set of hash computation routines now. But you are
right that the issues under discussion only affect hash indexes, not
in-memory hash tables.

> I know someone reported a problem with the hash indexes (data loss,
> serious)--- was that a new 7.4 but or something that has existed for a
> long time?

AFAICT the bug's been there since Berkeley days.

> When were you considering making these changes?

Now. We have three choices: fix it, ship 7.4 with a known data-loss
bug, or remove hash indexes. Which do you like?

regards, tom lane