Re: Don't process multi xmax in FreezeMultiXactId() if it is already marked as invalid.

On 2024-Jun-14, Anton A. Melnikov wrote:

> Hello!
> 
> The src/backend/access/heap/README.tuplock says about HEAP_XMAX_INVALID bit
> that "Any tuple with this bit set does not have a valid value stored in XMAX."
> 
> Found that FreezeMultiXactId() tries to process such an invalid multi xmax
> and may looks for an update xid in the pg_multixact for it.
> 
> Maybe not do this work in FreezeMultiXactId() and exit immediately if the
> bit HEAP_XMAX_INVALID was already set?
> 
> For instance, like that:
> 
> master
> @@ -6215,6 +6215,15 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
>         /* We should only be called in Multis */
>         Assert(t_infomask & HEAP_XMAX_IS_MULTI);
> +       /* Xmax is already marked as invalid */
> +       if (MultiXactIdIsValid(multi) &&
> +               (t_infomask & HEAP_XMAX_INVALID))

Hmm, but why are we calling FreezeMultiXactId at all if the
HEAP_XMAX_INVALID bit is set?  We shouldn't do that.  I think the fix
should appear in heap_prepare_freeze_tuple() to skip work completely if
HEAP_XMAX_INVALID is set.  Then in FreezeMultiXactId you could simply
Assert() that the given tuple does not have HEAP_XMAX_INVALID set.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there.  Did
somebody make percentages logarithmic while I wasn't looking?"
                http://smylers.hates-software.com/2005/09/08/1995c749.html