I'm looking at the code behind the foreign key checks in ri_triggers.c, and something's got me a little confused.
In both cases (FK insert/update checking the PK, and PK update/delete checking the FK) the check is done with a SELECT ... FOR KEY SHARE.
This makes perfect sense for PK checks, but in the FK check, it seems pointless at best; if it actually manages to find something to lock, it will fail the check and error out moments later. And in any case, I don't see how the key fields in the FK relation (to which the KEY SHARE lock applies) are even relevant to the constraint in question.