* heap_tuple_would_freeze
*
* Return value indicates if heap_prepare_freeze_tuple sibling function would
- * freeze any of the XID/XMID fields from the tuple, given the same cutoffs.
+ * freeze any of the XID/MXID fields from the tuple, given the same cutoffs.
* We must also deal with dead tuples here, since (xmin, xmax, xvac) fields
* could be processed by pruning away the whole tuple instead of freezing.
*
* oldestXmin and oldestMxact are the most recent values that can ever be
* passed to vac_update_relstats() as frozenxid and minmulti arguments by our
* vacuumlazy.c caller later on. These values should be passed when it turns
- * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
+ * out that VACUUM will leave no unfrozen XIDs/MXIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
#
# This provides test coverage for code paths that are only hit when we need to
# freeze, but inability to acquire a cleanup lock on a heap page makes
-# freezing some XIDs/XMIDs < FreezeLimit/MultiXactCutoff impossible (without
+# freezing some XIDs/MXIDs < FreezeLimit/MultiXactCutoff impossible (without
# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do).
permutation
dml_begin