Re: BUG #5952: SetRWConflict assertion failure

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #5952: SetRWConflict assertion failure
Дата
Msg-id BANLkTikA4fwzp5kxRS+69o0=GfO=x+sE5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5952: SetRWConflict assertion failure  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: BUG #5952: SetRWConflict assertion failure  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-bugs
On Sun, Mar 27, 2011 at 3:18 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> "YAMAMOTO Takashi" =A0wrote:
>
>> Description: SetRWConflict assertion failure
>
>> SerializableXactHashLock relocking in CheckTargetForConflictsIn()
>> seems racy to me.
>
> You're right. =A0The attached patch should fix the assertion you hit.

This patch looks reasonable, but I'm a bit concerned about the chunk
immediately preceding the patched area.

When we do this:

                    LWLockRelease(SerializableXactHashLock);
                    LWLockRelease(partitionLock);
                    LWLockRelease(SerializablePredicateLockListLock);
                    LWLockAcquire(partitionLock, LW_SHARED);
                    LWLockAcquire(SerializableXactHashLock, LW_SHARED);

Don't we need to also reset nextpredlock to the head of the list?  I'm
assuming it's the partitionLock that's keeping the PREDICATELOCKs from
bouncing out from under us, so if we release it, aren't we potentially
point off into thin air?

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Non Win/*nix UTF-8 codepage not known to PostgreSQL developers?!
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: BUG #5952: SetRWConflict assertion failure