On Tue, Sep 3, 2019 at 6:58 PM Heikki Linnakangas 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
On 03/09/2019 16:31, Tom Lane wrote:
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
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
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
