transactions
HINT:  To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>

    (A manual <command>VACUUM</command> should fix the problem, as suggested by the
    hint; but note that the <command>VACUUM</command> should be performed by a
    superuser, else it will fail to process system catalogs, which prevent it from
    being able to advance the database's <structfield>datfrozenxid</structfield>.)
    If these warnings are ignored, the system will refuse to assign new XIDs once
    there are fewer than three million transactions left until wraparound:

<programlisting>
ERROR:  database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
HINT:  Execute a database-wide VACUUM in that database.
</programlisting>

    In this condition any transactions already in progress can continue,
    but only read-only transactions can be started. Operations that
    modify database records or truncate relations will fail.
    The <command>VACUUM</command> command can still be run normally.
    Note that, contrary to what was sometimes recommended in earlier releases,
    it is not necessary or desirable to stop the postmaster or enter single
    user-mode in order to restore normal operation.
    Instead, follow these steps:

    <orderedlist>
     <listitem>
      <simpara>Resolve old prepared transactions. You can find these by checking
       <link linkend="view-pg-prepared-xacts">pg_prepared_xacts</link> for rows where
       <literal>age(transactionid)</literal> is large. Such transactions should be
       committed or rolled back.</simpara>
     </listitem>
     <listitem>
      <simpara>End long-running open transactions. You can find these by checking
       <link linkend="monitoring-pg-stat-activity-view">pg_stat_activity</link> for rows where
       <literal>age(backend_xid)</literal> or <literal>age(backend_xmin)</literal> is
       large. Such transactions should be committed or rolled back, or the session
       can be terminated using <literal>pg_terminate_backend</literal>.</simpara>
     </listitem>
     <listitem>
      <simpara>Drop any old replication slots. Use
       <link linkend="monitoring-pg-stat-replication-view">pg_stat_replication</link> to
       find slots where <literal>age(xmin)</literal> or <literal>age(catalog_xmin)</literal>
       is large. In many cases, such slots were created for replication to servers that no
       longer exist, or that have been down for a long time. If you drop a slot for a server
       that still exists and might still try to connect to that slot, that replica may
       need to be rebuilt.</simpara>
     </listitem>
     <listitem>
      <simpara>Execute <command>VACUUM</command> in the target database. A database-wide
       <literal>VACUUM</literal> is simplest; to reduce the time required, it as also possible
       to issue manual <command>VACUUM</command> commands on the tables where
       <structfield>relminxid</structfield> is oldest. Do not use <literal>VACUUM FULL</literal>
       in this scenario, because it requires an XID and will therefore fail, except in super-user
       mode, where it will instead consume an XID and thus increase the risk of transaction ID
       wraparound. Do not use <literal>VACUUM FREEZE</literal> either, because it will do
       more than the minimum amount of work required to restore normal operation.</simpara>
     </listitem>
     <listitem>
      <simpara>Once normal operation is restored, ensure that autovacuum is properly configured
       in the target database in order to avoid future problems.</simpara>
     </listitem>
    </orderedlist>
   </para>

   <note>
    <para>
     In earlier versions, it was sometimes necessary to stop the postmaster and
     <command>VACUUM</command> the database in a single-user mode. In typical scenarios, this
     is no longer necessary, and should be avoided whenever possible, since it involves taking