Re: BUG #5157: Hash index not concurrency safe
От | Tom Lane |
---|---|
Тема | Re: BUG #5157: Hash index not concurrency safe |
Дата | |
Msg-id | 23029.1257098909@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5157: Hash index not concurrency safe (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: BUG #5157: Hash index not concurrency safe
|
Список | pgsql-bugs |
I wrote: > Jeff Janes <jeff.janes@gmail.com> writes: >> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD. > Ouch. This used to be okay, because adding new entries to a hash page > always added them at the end. The 8.4 changes to keep individual hash > pages sorted by hashcode broke it :-(. Actually, now that I am looking at it, that patch COMPLETELY destroyed hash indexes. The search logic requires that index entries within a page are ordered by hash value. Although the insertion code preserves that property, neither _hash_splitbucket nor _hash_squeezebucket make any attempt to do so. So it's not just a transient concurrency issue, you can easily get corruption of a hash index leading to permanent search failures. Ugh. Mea culpa for letting this one through. regards, tom lane
В списке pgsql-bugs по дате отправления: