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

On Sun, Jan 24, 2021 at 9:31 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2021-Jan-24, Julien Rouhaud wrote:
>
> > +     /*
> > +      * Do not allow tuples with invalid combinations of hint bits to be placed
> > +      * on a page.  These combinations are detected as corruption by the
> > +      * contrib/amcheck logic, so if you disable one or both of these
> > +      * assertions, make corresponding changes there.
> > +      */
> > +     Assert(!((tuple->t_data->t_infomask & HEAP_XMAX_LOCK_ONLY) &&
> > +                      (tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED)));
> >
> >
> > I attach a simple self contained script to reproduce the problem, the last
> > UPDATE triggering the Assert.
> >
> > I'm not really familiar with this part of the code, so it's not exactly clear
> > to me if some logic is missing in compute_new_xmax_infomask() /
> > heap_prepare_insert(), or if this should actually be an allowed combination of
> > hint bit.
>
> Hmm, it's probably a bug in compute_new_xmax_infomask.  I don't think
> the combination is sensible.
>

If we see the logic of GetMultiXactIdHintBits then it appeared that we
can get this combination in the case of multi-xact.

switch (members[i].status)
{
...
   case MultiXactStatusForUpdate:
   bits2 |= HEAP_KEYS_UPDATED;
   break;
}

....
if (!has_update)
bits |= HEAP_XMAX_LOCK_ONLY;

Basically, if it is "select for update" then we will mark infomask2 as
HEAP_KEYS_UPDATED and the informask as HEAP_XMAX_LOCK_ONLY.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com