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
|
Список | 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 по дате отправления: