Re: BUG #5157: Hash index not concurrency safe

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: BUG #5157: Hash index not concurrency safe
Дата
Msg-id f67928030911010917w47735e6ar759f567b98ad7b73@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5157: Hash index not concurrency safe  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #5157: Hash index not concurrency safe  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BUG #5157: Hash index not concurrency safe  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jeff Janes" <jeff.janes@gmail.com> writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
>
> Ouch. =A0This used to be okay, because adding new entries to a hash page
> always added them at the end. =A0The 8.4 changes to keep individual hash
> pages sorted by hashcode broke it :-(.
>
> I think we could recover by having the hashgettuple code path
> re-synchronize by looking for the heap TID it previously returned.
> That must be at the same or higher index TID as we had stopped at.
> (Deletions are not possible, so we only have to search forward,
> and the TID must be there someplace.)

Can it get pushed to another page (an overflow page)?  My quick
reading of the code suggests it can't get pushed, which makes the fix
easier.

I'll work on a fix for it.  But if 8.4.2 is coming out in the next
couple of weeks and we want the fix to be in it, then we might want
someone more proficient than me to work on it.

Cheers,

Jeff

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5157: Hash index not concurrency safe
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5157: Hash index not concurrency safe