Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Date: 2021-02-01 10:35:08
Message-ID: CAOBaU_Y3HYwTi5VA5X+Tijyot-fenAfV=Mj6ZchkBh=i9ZB-GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 1, 2021 at 2:05 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sun, Jan 24, 2021 at 9:31 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

Yes I saw that too, I don't know if the MultiXactStatusForUpdate case
is ok or not.

Note that this hint bit can get cleaned later in heap_update in case
of hot_update or if there's TOAST:

/*
* To prevent concurrent sessions from updating the tuple, we have to
* temporarily mark it locked, while we release the page-level lock.
[...]
/* Clear obsolete visibility flags ... */
oldtup.t_data->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
oldtup.t_data->t_infomask2 &= ~HEAP_KEYS_UPDATED;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2021-02-01 10:42:03 Re: How to expose session vs txn lock info in pg_locks view?
Previous Message Dilip Kumar 2021-02-01 09:32:56 Re: Printing backtrace of postgres processes