Adjust comments that called MultiXactIds "XMIDs".

Oversights in commits 0b018fab and f3c15cbe.

src/backend/access/heap/heapam.c

@@ -7218,7 +7218,7 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
  * 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.
  *

src/backend/commands/vacuum.c

@@ -951,7 +951,7 @@ get_all_vacuum_rels(int options)
  * 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,

src/test/isolation/specs/vacuum-no-cleanup-lock.spec

@@ -127,7 +127,7 @@ permutation
 #
 # 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