Re: Preliminary notes about hash index concurrency (long)

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.
> AFAICS the only way to fix this is to prevent such a concurrent split.
> Accordingly, I've been trying to redesign the hash index locking
> mechanisms to make that possible, and while I'm at it eliminate the
> various internal deadlock risks that presently exist in hash indexes.
> Attached are some design notes --- any comments?

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

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. I
assume these changes are for hash indexes.

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? When were you considering making these changes?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073