On 2024-Jun-19, Peter Geoghegan wrote: > On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov <y.soko...@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/
