On Tue, Sep 3, 2019 at 6:58 PM Heikki Linnakangas <hlinn...@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
