On Tue, Sep 3, 2019 at 6:58 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> 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 :-(.
>
Can't we pass the wait_policy parameter to heap_lock_updated_tuple and
do the same handling as we do in the caller (heap_lock_tuple)?
Basically, whenever we need to wait on any tuple version do the same
as we do in heap_lock_tuple for 'require_sleep' case.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com