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