When you lock a row with FOR KEY SHARE, and the row's non-key columns
have been updated, heap_lock_tuple() walks the update chain to mark all
the in-progress tuple versions also as locked. But it doesn't pay
attention to the NOWAIT or SKIP LOCKED flags when doing so. The
heap_lock_updated_tuple() function walks the update chain, but the
'wait_policy' argument is not passed to it. As a result, a SELECT in KEY
SHARE NOWAIT query can block waiting for another updating transaction,
despite the NOWAIT modifier.
This can be reproduced with the attached isolation test script.
I'm not sure how to fix this. The logic to walk the update chain and
propagate the tuple lock is already breathtakingly complicated :-(.
- Heikki
