diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 137175ca3b5..fc89c03279b 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -789,8 +789,8 @@ HINT:  Execute a database-wide VACUUM in that database.
      32-bit counter and corresponding storage, all of which requires
      careful aging management, storage cleanup, and wraparound handling.
      There is a separate storage area which holds the list of members in
-     each multixact, which also uses a 32-bit counter and which must also
-     be managed.  The system function
+     each multixact, which cannot wrap around but must also be managed
+     to keep disk usage under control.  The system function
      <function>pg_get_multixact_members()</function> described in
      <xref linkend="functions-pg-snapshot"/> can be used to examine the
      transaction IDs associated with a multixact ID.
@@ -824,16 +824,13 @@ HINT:  Execute a database-wide VACUUM in that database.
     <para>
      As a safety device, an aggressive vacuum scan will
      occur for any table whose multixact-age is greater than <xref
-     linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the number
-     of multixact member entries created exceeds approximately 2 billion
-     entries (occupying roughly 10GB in the
+     linkend="guc-autovacuum-multixact-freeze-max-age"/>. The aggressive
+     scans will occur even if autovacuum is nominally disabled. Also, if
+     the number of multixact member entries created exceeds approximately
+     2 billion entries (occupying roughly 10GB in the
      <literal>pg_multixact/members</literal> directory), aggressive vacuum
      scans will occur more often for all tables, starting with those that
-     have the oldest multixact-age. Both of these kinds of aggressive
-     scans will occur even if autovacuum is nominally disabled. At approximately
-     4 billion entries (occupying roughly 20GB in the
-     <literal>pg_multixact/members</literal> directory), even more aggressive
-     vacuum scans are triggered to reclaim member storage space.
+     have the oldest multixact-age.
     </para>
 
     <para>
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 3caedb54850..7ef09df3b30 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -997,9 +997,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
 	 * against catastrophic data loss due to multixact wraparound.  The basic
 	 * rules are:
 	 *
-	 * If we're past multiVacLimit or the safe threshold for member storage
-	 * space, or we don't know what the safe threshold for member storage is,
-	 * start trying to force autovacuum cycles.
+	 * If we're past multiVacLimit, start trying to force autovacuum cycles.
 	 * If we're past multiWarnLimit, start issuing warnings.
 	 * If we're past multiStopLimit, refuse to create new MultiXactIds.
 	 *
@@ -2167,7 +2165,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
 	 * Offsets are 64-bits wide and never wrap around, so we don't need to
 	 * consider them for emergency autovacuum purposes.  But now that we're in
 	 * a consistent state, determine MultiXactState->oldestOffset.  It will be
-	 * used to adjust the freezing cutoff, to keep the offsets disk usage in
+	 * used to adjust the freezing cutoff, to keep the members disk usage in
 	 * check.
 	 */
 	SetOldestOffset();