multixact ID it encounters which is older than
     <xref linkend="guc-vacuum-multixact-freeze-min-age"/>
     by a different value, which can be the zero value, a single
     transaction ID, or a newer multixact ID.  For each table,
     <structname>pg_class</structname>.<structfield>relminmxid</structfield> stores the oldest
     possible multixact ID still appearing in any tuple of that table.
     If this value is older than
     <xref linkend="guc-vacuum-multixact-freeze-table-age"/>, an aggressive
     vacuum is forced.  As discussed in the previous section, an aggressive
     vacuum means that only those pages which are known to be all-frozen will
     be skipped.  <function>mxid_age()</function> can be used on
     <structname>pg_class</structname>.<structfield>relminmxid</structfield> to find its age.
    </para>

    <para>
     Aggressive <command>VACUUM</command>s, regardless of what causes
     them, are <emphasis>guaranteed</emphasis> to be able to advance
     the table's <structfield>relminmxid</structfield>.
     Eventually, as all tables in all databases are scanned and their
     oldest multixact values are advanced, on-disk storage for older
     multixacts can be removed.
    </para>

    <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
     storage occupied by multixacts members exceeds about 10GB, 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. The members storage
     area can grow up to about 20GB before reaching wraparound.
    </para>

    <para>
     Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
     system will begin to emit warning messages when the database's oldest MXIDs reach forty
     million transactions from the wraparound point.  And, just as in the XID case, if these
     warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
     than three million left until wraparound.
    </para>

    <para>
     Normal operation when MXIDs are exhausted can be restored in much the same way as
     when XIDs are exhausted. Follow the same steps in the previous section, but with the
     following differences:

    <orderedlist>
     <listitem>
      <simpara>Running transactions and prepared transactions can be ignored if there
       is no chance that they might appear in a multixact.</simpara>
     </listitem>
     <listitem>
      <simpara>MXID information is not directly visible in system views such as
       <literal>pg_stat_activity</literal>; however, looking for old XIDs is still a good
       way of determining which transactions are causing MXID wraparound problems.</simpara>
     </listitem>
     <listitem>
      <simpara>XID exhaustion will block all write transactions, but MXID exhaustion will
       only block a subset of write transactions, specifically those that involve
       row locks that require an MXID.</simpara>
     </listitem>
    </orderedlist>
   </para>

   </sect3>
  </sect2>

  <sect2 id="autovacuum">
   <title>The Autovacuum Daemon</title>

   <indexterm>
    <primary>autovacuum</primary>
    <secondary>general information</secondary>
   </indexterm>
   <para>
    <productname>PostgreSQL</productname> has an optional but highly
    recommended feature called <firstterm>autovacuum</firstterm>,
    whose purpose is to automate the execution of
    <command>VACUUM</command> and <command>ANALYZE</command> commands.
    When enabled, autovacuum checks for
    tables that have had a large number of inserted, updated or deleted
    tuples.  These checks use the statistics collection facility;
    therefore, autovacuum cannot be used unless <xref
    linkend="guc-track-counts"/> is set