Date: Thu, 4 Feb 2021 13:22:35 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Mahendra Singh Thalor <mahi6run@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit
 combination
Message-ID: <20210204162235.GA18329@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210204160624.GA22612@nol>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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)