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
