Re: Maybe don't process multi xmax in FreezeMultiXactId() if it is already marked as invalid?

On 2024-Jun-19, Peter Geoghegan wrote:

> On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)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/