Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Date
Msg-id 20210204162235.GA18329@alvherre.pgsql
Whole thread Raw
In response to Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
List pgsql-hackers
On 2021-Feb-05, Julien Rouhaud wrote:

>  - HEAP_KEYS_UPDATED
>    This bit lives in t_infomask2.  If set, indicates that the XMAX updated
> -  this tuple and changed the key values, or it deleted the tuple.
> -  It's set regardless of whether the XMAX is a TransactionId or a MultiXactId.
> +  this tuple and changed the key values, or it deleted the tuple.  It can also
> +  be set in combination of HEAP_XMAX_LOCK_ONLY.  It's set regardless of whether
> +  the XMAX is a TransactionId or a MultiXactId.

I think we should reword this more completely, to avoid saying one thing
(that the op is an update or delete) and then contradicting ourselves
(that it can also be a lock).  I propose this:

    This bit lives in t_infomask2.  If set, it indicates that the
    operation(s) done by the XMAX compromise the tuple key, such as
    a SELECT FOR UPDATE, an UPDATE that modifies the columns of the
    key, or a DELETE.

Also, I just noticed that the paragraph just above this one says that
HEAP_XMAX_EXCL_LOCK is used for both SELECT FOR UPDATE and SELECT FOR NO
KEY UPDATE, and that this bit is what differentiates them.

-- 
Álvaro Herrera       Valdivia, Chile
"Oh, great altar of passive entertainment, bestow upon me thy discordant images
at such speed as to render linear thought impossible" (Calvin a la TV)



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Julien Rouhaud
Date:
Subject: Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination