Re: BUG #5952: SetRWConflict assertion failure

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp, pgsql-bugs(at)postgresql(dot)org, drkp(at)csail(dot)mit(dot)edu
Subject: Re: BUG #5952: SetRWConflict assertion failure
Date: 2011-04-05 14:56:51
Message-ID: BANLkTikA4fwzp5kxRS+69o0=GfO=x+sE5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Mar 27, 2011 at 3:18 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> "YAMAMOTO Takashi"  wrote:
>
>> Description: SetRWConflict assertion failure
>
>> SerializableXactHashLock relocking in CheckTargetForConflictsIn()
>> seems racy to me.
>
> You're right.  The 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?

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2011-04-05 15:18:39 Re: BUG #5952: SetRWConflict assertion failure
Previous Message Heikki Linnakangas 2011-04-05 05:33:18 Re: Non Win/*nix UTF-8 codepage not known to PostgreSQL developers?!