Re: BUG #5952: SetRWConflict assertion failure
От | Robert Haas |
---|---|
Тема | Re: BUG #5952: SetRWConflict assertion failure |
Дата | |
Msg-id | BANLkTim0oG9XeHCFGF7FUNh5wBj7aXSbZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5952: SetRWConflict assertion failure ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: BUG #5952: SetRWConflict assertion failure
|
Список | pgsql-bugs |
On Tue, Apr 5, 2011 at 11:18 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Robert Haas <robertmhaas@gmail.com> wrote: >> This patch looks reasonable, but I'm a bit concerned about the >> chunk immediately preceding the patched area. >> >> When we do this: >> >> =A0 =A0 LWLockRelease(SerializableXactHashLock); >> =A0 =A0 LWLockRelease(partitionLock); >> =A0 =A0 LWLockRelease(SerializablePredicateLockListLock); >> =A0 =A0 LWLockAcquire(partitionLock, LW_SHARED); >> =A0 =A0 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? > > I think you are right. =A0That sequence should be followed by a copy > of the same "nextpredlock =3D " statement that's just above. =A0Do you > want me to revise the patch or do you just want to take care of it > as part of the commit? > > Thanks for catching that. If you could send a revised patch, that would be great. I don't want to muck it up by accident. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: