# Fixing foreign key deadlocks, part 2  revisited

> 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…

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.

---
[View this page online](https://www.commandprompt.com/blog/fixing_foreign_key_deadlocks_part_2__revisited/)