Fixing foreign key deadlocks, part 2 revisited
Posted Thursday Nov 25th, 2010 12:02pm
by Alvaro Herrera | Permalink

While trying to implement SELECT FOR KEY LOCK at the lock manager level, I stumbled across the problem that I need to represent the lock faithfully in the lock manager's terms. And since I previously mentioned that FOR KEY LOCK would conflict with FOR SHARE, I get in trouble — it's not easy to see which lock mode to use (if there is one, which I doubt).

So I revisited that decision: a FOR KEY LOCK does not conflict with FOR SHARE, and this allows them to use the same ShareLock mode.

This has two consequences:

1. After the tuple is locked by two transactions or more in the two different modes, there's no way to figure out which one has which lock.
2. The HEAP_XMAX_SHARED_LOCK infomask bit needs to be carried forward in an UPDATE, just like HEAP_XMAX_KEY_LOCK bit was going to be.

None of these is a problem, as far as I can see. Just a little bit different. But the basic fact that FOR SHARE and FOR KEY LOCK do not conflict could take someone by surprise.

---

blog comments powered by Disqus