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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
ssi-recheck-conflict-in-before-flagging.patch application/octet-stream 1.1 KB

Responses

Browse pgsql-bugs by date

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