On Sun, Jan 24, 2021 at 9:31 PM Alvaro Herrera <alvhe...@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
