Re: BUG #5952: SetRWConflict assertion failure - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #5952: SetRWConflict assertion failure
Date
Msg-id BANLkTim0oG9XeHCFGF7FUNh5wBj7aXSbZg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5952: SetRWConflict assertion failure  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: BUG #5952: SetRWConflict assertion failure
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5952: SetRWConflict assertion failure
Next
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5952: SetRWConflict assertion failure