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

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))
+       {
+               *flags |= FRM_INVALIDATE_XMAX;
+               pagefrz->freeze_required = true;
+               return InvalidTransactionId;
+       }
+
         if (!MultiXactIdIsValid(multi) ||
                 HEAP_LOCKED_UPGRADED(t_infomask))


With the best regards,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On 14.06.2024 10:45, Anton A. Melnikov wrote:

> 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?
> 

Seems it is important to save the check that multi xmax is not behind relminmxid.
So saved it and correct README.tuplock accordingly.

Would be glad if someone take a look at the patch attached.


With the best regards,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Tue, Jun 18, 2024 at 10:29 AM Maxim Orlov <orlovmg@gmail.com> wrote:
> Maybe, I'm too bold, but looks like a kinda bug to me.  At least, I don't understand why we do not check the
HEAP_XMAX_INVALIDflag. 
> My guess is nobody noticed, that MultiXactIdIsValid call does not check the mentioned flag in the "first" condition,
butit's all my speculation. 

A related code path was changed in commit 02d647bbf0. That change made
the similar xmax handling that covers XIDs (not MXIDs) *stop* doing
what you're now proposing to do in the Multi path.

Why do you think this is a bug?

> Does anyone know if there are reasons to deliberately ignore the HEAP_XMAX INVALID flag? Or this is just an
unfortunateoversight. 

HEAP_XMAX_INVALID is just a hint.

--
Peter Geoghegan

18.06.2024 18:47, Peter Geoghegan пишет:
> On Tue, Jun 18, 2024 at 10:29 AM Maxim Orlov <orlovmg@gmail.com> wrote:
>> Maybe, I'm too bold, but looks like a kinda bug to me.  At least, I don't understand why we do not check the
HEAP_XMAX_INVALIDflag.
 
>> My guess is nobody noticed, that MultiXactIdIsValid call does not check the mentioned flag in the "first" condition,
butit's all my speculation.
 
> 
> A related code path was changed in commit 02d647bbf0. That change made
> the similar xmax handling that covers XIDs (not MXIDs) *stop* doing
> what you're now proposing to do in the Multi path.

I don't agree commit 02d647bbf0 is similar to suggested change.
Commit 02d647bbf0 fixed decision to set
    freeze_xmax = false;
    xmax_already_frozen = true;

Suggested change is for decision to set
    *flags |= FRM_INVALIDATE_XMAX;
    pagefrz->freeze_required = true;
Which leads to
    freeze_xmax = true;

So it is quite different code paths, and one could not be used
to decline or justify other.

More over, certainly test on HEAP_XMAX_INVALID could be used
there in heap_prepare_freeze_tuple to set
    freeze_xmax = true;
Why didn't you do it?

> 
> Why do you think this is a bug?

It is not a bug per se.
But:
- it is missed opportunity for optimization,
- it is inconsistency in data handling.
Inconsistency leads to bugs when people attempt to modify code.

Yes, we changed completely different place mistakenly relying on 
consistent reaction on this "hint", and that leads to bug in our
patch.

>> Does anyone know if there are reasons to deliberately ignore the HEAP_XMAX INVALID flag? Or this is just an
unfortunateoversight.
 
> 
> HEAP_XMAX_INVALID is just a hint.
> 

WTF is "just a hint"?
I thought, hint is "yep, you can ignore it. But we already did some job 
and stored its result as this hint. And if you don't ignore this hint, 
then you can skip doing the job we did already".

So every time we ignore hint, we miss opportunity for optimization.
Why the hell we shouldn't optimize when we safely can?

If we couldn't rely on hint, then hint is completely meaningless.

--------

have a nice day

Yura Sokolov

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

On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
> So it is quite different code paths, and one could not be used
> to decline or justify other.

The point is that we shouldn't need to rely on what is formally a
hint. It might be useful to use the hint to decide whether or not
freezing now actually makes sense, but that isn't the same thing as
relying on the hint (we could make the same decision for a number of
different reasons).

> More over, certainly test on HEAP_XMAX_INVALID could be used
> there in heap_prepare_freeze_tuple to set
>         freeze_xmax = true;
> Why didn't you do it?

You might as well ask me why I didn't do any number of other things. I
actually wrote a patch that made FreezeMultiXactId() more aggressive
about this sort of thing (setting HEAP_XMAX_INVALID) that targeted
Postgres 16. That worked by noticing that every member XID was at
least before OldestXmin, even when the MXID itself was >= OldestMxact.
That didn't go anywhere, even though it was a perfectly valid
optimization.

It's true that FreezeMultiXactId() optimizations like this are
possible. So what?

> It is not a bug per se.
> But:
> - it is missed opportunity for optimization,
> - it is inconsistency in data handling.
> Inconsistency leads to bugs when people attempt to modify code.

In what sense is there an inconsistency?

I think that you must mean that we need to do the same thing for the
!MultiXactIdIsValid() case and the already-HEAP_XMAX_INVALID case. But
I don't think that that's any meaningful kind of inconsistency. It's
*also* what we do with plain XIDs. If anything, the problem is that
we're *too* consistent (ideally we *would* treat MultiXacts
differently).

> Yes, we changed completely different place mistakenly relying on
> consistent reaction on this "hint", and that leads to bug in our
> patch.

Oooops!

> > HEAP_XMAX_INVALID is just a hint.
> >
>
> WTF is "just a hint"?
> I thought, hint is "yep, you can ignore it. But we already did some job
> and stored its result as this hint. And if you don't ignore this hint,
> then you can skip doing the job we did already".
>
> So every time we ignore hint, we miss opportunity for optimization.
> Why the hell we shouldn't optimize when we safely can?

This is the first email that anybody has used the word "optimization".
We've been discussing this as if it was a bug. You introduced the
topic of optimization 3 seconds ago. Remember?

> If we couldn't rely on hint, then hint is completely meaningless.

We don't actually trust the hints in any way. We always run checks
inside heap_pre_freeze_checks(), rather than assuming that the hints
are accurate.

--
Peter Geoghegan

On 2024-Jun-19, Peter Geoghegan wrote:

> On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
> > So it is quite different code paths, and one could not be used
> > to decline or justify other.
> 
> The point is that we shouldn't need to rely on what is formally a
> hint. It might be useful to use the hint to decide whether or not
> freezing now actually makes sense, but that isn't the same thing as
> relying on the hint (we could make the same decision for a number of
> different reasons).

FWIW I don't think HEAP_XMAX_INVALID as purely a hint.
HEAP_XMAX_COMMITTED is a hint, for sure, as is HEAP_XMIN_COMMITTED on
its own; but as far as I recall, the INVALID flags must persist once
set.  Consider the HEAP_XMIN_COMMITTED+ HEAP_XMIN_INVALID combination,
which we use to represent HEAP_XMIN_FROZEN; if that didn't persist, we'd
have a pretty serious data corruption issue, because we don't reset the
Xmin field when freezing the tuple.  So if we fail to keep the flag, the
tuple is no longer frozen.  (My point here is that some infomask bits
are hints, but not all them are only hints.)   So XMAX_INVALID gives
certainty that the Xmax value must not be read.  That is to say, I think
there are (or there were) situations in which we set the bit but don't
bother to reset the actual Xmax field.  We should never try to read the
Xmax flag if the bit is set.

I think the problem being investigated in this thread is that
HEAP_XMAX_IS_MULTI is being treated as persistent, that is, it can only
be set if the xmax is not invalid, but apparently that's not always the
case (or we wouldn't be having this conversation).

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

On Wed, Jun 19, 2024 at 1:39 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> FWIW I don't think HEAP_XMAX_INVALID as purely a hint.
> HEAP_XMAX_COMMITTED is a hint, for sure, as is HEAP_XMIN_COMMITTED on
> its own; but as far as I recall, the INVALID flags must persist once
> set.

Seems we disagree on some pretty fundamental things in this area, then.

> Consider the HEAP_XMIN_COMMITTED+ HEAP_XMIN_INVALID combination,
> which we use to represent HEAP_XMIN_FROZEN; if that didn't persist, we'd
> have a pretty serious data corruption issue, because we don't reset the
> Xmin field when freezing the tuple.

That's definitely true, but that's a case where the setting happens during a
WAL-logged operation. It doesn't involve HEAP_XMAX_INVALID at all.

FWIW I also don't think that even HEAP_XMIN_INVALID should be
considered anything more than a hint when it appears on its own. Only
HEAP_XMIN_FROZEN (by which I mean HEAP_XMIN_COMMITTED +
HEAP_XMIN_INVALID) are non-hint xact status infomask bits.

It's slightly annoying that we have this HEAP_XMIN_FROZEN case where a
hint bit isn't just a hint, but that's just a historical detail. And I
suppose that the same thing can be said of HEAP_XMAX_IS_MULTI itself
(we have no other way of distinguishing a Multi from an Xid, so
clearly that also has to be treated as a persistent non-hint by everybody).

> So if we fail to keep the flag, the
> tuple is no longer frozen.  (My point here is that some infomask bits
> are hints, but not all them are only hints.)   So XMAX_INVALID gives
> certainty that the Xmax value must not be read.

"Certainty" seems far too strong here.

> That is to say, I think
> there are (or there were) situations in which we set the bit but don't
> bother to reset the actual Xmax field.

I'm sure that that's true, but that doesn't seem at all equivalent to
what you said about XMAX_INVALID "giving certainty" about the tuple.

> We should never try to read the
> Xmax flag if the bit is set.

But that's exactly what FreezeMultiXactId does. It doesn't pay
attention to XMAX_INVALID (only to !MultiXactIdIsValid()).

Yura is apparently arguing that FreezeMultiXactId should notice
XMAX_INVALID and then tell its caller to "FRM_INVALIDATE_XMAX". That
does seem like a valid optimization. But if we were to do that then
we'd likely do it in a way that still resulted in ordinary processing
of the multi (it would not work by immediately setting
"FRM_INVALIDATE_XMAX" in the !MultiXactIdIsValid() path). That
approach to the optimization makes the most sense, because we'd likely
want to preserve the existing FreezeMultiXactId sanity checks.

> I think the problem being investigated in this thread is that
> HEAP_XMAX_IS_MULTI is being treated as persistent, that is, it can only
> be set if the xmax is not invalid, but apparently that's not always the
> case (or we wouldn't be having this conversation).

A multixact/HEAP_XMAX_IS_MULTI xmax doesn't start out as invalid.
Treating HEAP_XMAX_IS_MULTI as persistent doesn't mean that we should
treat XMAX_INVALID as consistent. In particular, XMAX_INVALID isn't
equivalent to !MultiXactIdIsValid() (you can make a similar statement
about xmax XIDs).


--
Peter Geoghegan