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:
- 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.
- 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.