Skip site navigation (1) Skip section navigation (2)

Re: BUG #5952: SetRWConflict assertion failure

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>,<pgsql-bugs(at)postgresql(dot)org>
Cc: <drkp(at)csail(dot)mit(dot)edu>
Subject: Re: BUG #5952: SetRWConflict assertion failure
Date: 2011-03-27 19:18:45
Message-ID: 4D8F4745020000250003BCFA@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
"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.
 
I will take a close look at the code above the patched area (for the
optimization to drop the predicate lock when we acquire a write
lock).  Looking at it just now I'm wondering if it really is a safe
optimization in PostgreSQL.  It was in the Cahill paper, but InnoDB
doesn't have subtransactions.  I fear that we could give up the
SIReadLock within a subtransaction and then have problems if the
subtransaction rolls back, effectively discarding the write lock.  I
suspect we need to do this only if we're not within a subtransaction.
Will follow up on that after further review.
 
Thanks!
 
-Kevin

Attachment: ssi-recheck-conflict-in-before-flagging.patch
Description: application/octet-stream (1.1 KB)

Responses

pgsql-bugs by date

Next:From: Robert HaasDate: 2011-03-28 04:25:05
Subject: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Previous:From: Kevin GrittnerDate: 2011-03-27 18:23:12
Subject: Re: BUG #5953: pgadmin sql-query text pad doesn't work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group