Re: Locking a row with KEY SHARE NOWAIT blocks

Heikki Linnakangas  writes:
> 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 :-(.

Why are we locking any but the most recent version?

			regards, tom lane