Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Mahendra Singh Thalor <mahi6run@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-04T16:37:50Z
Lists: pgsql-hackers

Attachments

On Thu, Feb 04, 2021 at 01:22:35PM -0300, Alvaro Herrera wrote:
> 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.

Thanks, that's way better, copied in v3.  I'm still a bit worried about that
description though, as that flag isn't consistently set for the FOR UPDATE
case.  Well, to be more precise it's maybe consistently set when the hint bits
are computed, but in some cases the flag is later cleared, so you won't
reliably find it in the tuple.

Commits

  1. Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed