<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 to <literal>true</literal>.
    In the default configuration, autovacuuming is enabled and the related
    configuration parameters are appropriately set.
   </para>

   <para>
    The <quote>autovacuum daemon</quote> actually consists of multiple processes.
    There is a persistent daemon process, called the
    <firstterm>autovacuum launcher</firstterm>, which is in charge of starting
    <firstterm>autovacuum worker</firstterm> processes for all databases. The
    launcher will distribute the work across time, attempting to start one
    worker within each database every <xref linkend="guc-autovacuum-naptime"/>
    seconds.  (Therefore, if the installation has <replaceable>N</replaceable> databases,
    a new worker will be launched every
    <varname>autovacuum_naptime</varname>/<replaceable>N</replaceable> seconds.)
    A maximum of <xref linkend="guc-autovacuum-max-workers"/> worker processes
    are allowed to run at the same time. If there are more than
    <varname>autovacuum_max_workers</varname> databases to be processed,
    the next database will be processed as soon as the first worker finishes.
    Each worker process will check each table within its database and
    execute <command>VACUUM</command> and/or <command>ANALYZE</command> as needed.
    <xref linkend="guc-log-autovacuum-min-duration"/> can be set to monitor
    autovacuum workers' activity.
   </para>

   <para>
    If several large tables all become eligible for vacuuming in a short
    amount of time, all autovacuum workers might become occupied with
    vacuuming those tables for a long period.  This would result
    in other tables and databases not being vacuumed until a worker becomes
    available. There is no limit on how many workers might be in a
    single database, but workers do try to avoid repeating work that has
    already been done by other workers. Note that the number of running
    workers does not count towards <xref linkend="guc-max-connections"/> or
    <xref linkend="guc-superuser-reserved-connections"/> limits.
   </para>

   <para>
    Tables whose <structfield>relfrozenxid</structfield> value is more than
    <xref linkend="guc-autovacuum-freeze-max-age"/> transactions old are always
    vacuumed (this also applies to those tables whose freeze max age has
    been modified via storage parameters; see below).  Otherwise, if the
    number of tuples obsoleted since the last
    <command>VACUUM</command> exceeds the <quote>vacuum threshold</quote>, the
    table is vacuumed.  The vacuum threshold is defined as:
<programlisting>
vacuum threshold = Minimum(vacuum max threshold, vacuum base threshold + vacuum scale factor * number of tuples)
</programlisting>
    where the vacuum max threshold is
    <xref linkend="guc-autovacuum-vacuum-max-threshold"/>,
    the vacuum base threshold is
    <xref linkend="guc-autovacuum-vacuum-threshold"/>,
    the vacuum scale factor is
    <xref linkend="guc-autovacuum-vacuum-scale-factor"/>,
    and the number