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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073