RE: Re: [SQL] possible row locking bug in 7.0.3 & 7.1

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: Re: [SQL] possible row locking bug in 7.0.3 & 7.1
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D335E@sectorbase1.sectorbase.com
обсуждение исходный текст
Список pgsql-hackers
> > >> I assume this is not possible in 7.1?
> > >
> > >Just looked in heapam.c - I can fix it in two hours.
> > >The question is - should we do this now?
> > >Comments?
> > 
> > It's a bug; how confident are you of the fix?

95% -:)

> I doubt if it's a bug of SELECT. Well what
> 'concurrent UPDATE then SELECT FOR UPDATE +
> SELECT' return ?

I'm going to add additional check to heapgettup and
heap_fetch:

HeapTupleSatisfies(T) is TRUE:

IF XactIsoLevel is READ_COMMITTED
and snapshot != SnapshotDirty
and !(T->t_data->t_infomask & HEAP_XMAX_INVALID)
and T->t_data->t_infomask & HEAP_XMAX_COMMITTED
and T->t_self != T->t_data->t_ctid
{ FOR ( ; ; ) {   fetch tuple->t_data->t_ctid tuple   IF t_infomask & (HEAP_XMAX_INVALID | HEAP_MARKED_FOR_UPDATE)
break;-- and return T   IF t_infomask & HEAP_XMAX_COMMITTED   {     IF t_self != ctid    -- updated       continue;
break;-- deleted, return T   }   -- uncommitted update/delete   IF t_xmax != CurrentTransactionID     break; -- and
returnT   -- changed by current TX!   IF changed *BEFORE* this query began   {     -- DELETE + SELECT: nothing to
return    -- UPDATE + SELECT: newer tuple version     -- will be/was returned by query     return NULL;   }   continue;
}
}

Vadim


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

Предыдущее
От: Matthew
Дата:
Сообщение: RE: User administration tool
Следующее
От: Adriaan Joubert
Дата:
Сообщение: Re: Unsigned int functions