A week ago, I submitted my patch to fix the foreign key lock problem. What I propose is almost exactly what was described in my previous blog posts, with a couple of differences.

The first is that I decided to only check unique indexes, not all indexes. This is good because you can have other indexes for performance and they will not affect locking for foreign keys. I noticed that it could be done easily without performance impact, and it had been requested by at least two independent people.

(For the hardcore hackers among you, the way I did this was by adding a second bitmapset to the relcache RelationData struct, which lists columns part of unique indexes. This second bms is computed in parallel of the bms used to do the HOT checks, and both are cached at the same time in the relcache entry, and the uniqueness info was already available there, so there are no extra catalog lookups to do this.)

The other difference, as I commented on a previous post, is that FOR KEY LOCK does not conflict with FOR SHARE. This shouldn't be too problematic, although there is one catch: if a tuple is share-locked, and then there's a constant stream for key-lockers, someone trying to update the tuple might be locked out for a long time, even if the share-locker goes away.

Now the patch is waiting for review on the commitfest. If you have a pet test case that could be affected by this patch, please try it out and let me know your thoughts and/or results.