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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
