</para>
    </listitem>

   </varlistentry>

   <varlistentry>
    <term><envar>PG_COLOR</envar></term>
    <listitem>
     <para>
      Specifies whether to use color in diagnostic messages. Possible values
      are <literal>always</literal>, <literal>auto</literal> and
      <literal>never</literal>.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   This utility, like most other <productname>PostgreSQL</productname> utilities,
   also uses the environment variables supported by <application>libpq</application>
   (see <xref linkend="libpq-envars"/>).
  </para>

 </refsect1>

 <refsect1 id="app-pgdump-diagnostics">
  <title>Diagnostics</title>

  <para>
   <application>pg_dump</application> internally executes
   <command>SELECT</command> statements. If you have problems running
   <application>pg_dump</application>, make sure you are able to
   select information from the database using, for example, <xref
   linkend="app-psql"/>.  Also, any default connection settings and environment
   variables used by the <application>libpq</application> front-end
   library will apply.
  </para>

  <para>
   The database activity of <application>pg_dump</application> is
   normally collected by the cumulative statistics system.  If this is
   undesirable, you can set parameter <varname>track_counts</varname>
   to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
   USER</literal> command.
  </para>

 </refsect1>


 <refsect1 id="pg-dump-notes">
  <title>Notes</title>

  <para>
   If your database cluster has any local additions to the <literal>template1</literal> database,
   be careful to restore the output of <application>pg_dump</application> into a
   truly empty database; otherwise you are likely to get errors due to
   duplicate definitions of the added objects.  To make an empty database
   without any local additions, copy from <literal>template0</literal> not <literal>template1</literal>,
   for example:
<programlisting>
CREATE DATABASE foo WITH TEMPLATE template0;
</programlisting>
  </para>

  <para>
   When a dump without schema is chosen and the option <option>--disable-triggers</option>
   is used, <application>pg_dump</application> emits commands
   to disable triggers on user tables before inserting the data,
   and then commands to re-enable them after the data has been
   inserted.  If the restore is stopped in the middle, the system
   catalogs might be left in the wrong state.
  </para>

  <para>
   If <option>--with-statistics</option> is specified,
   <command>pg_dump</command> will include most optimizer statistics in the
   resulting dump file.  However, some statistics may not be included, such as
   those created explicitly with <xref linkend="sql-createstatistics"/> or
   custom statistics added by an extension.  Therefore, it may be useful to
   run <command>ANALYZE</command> after restoring from a dump file to ensure
   optimal performance; see <xref linkend="vacuum-for-statistics"/> and <xref
   linkend="autovacuum"/> for more information.
  </para>

  <para>
   Because <application>pg_dump</application> is used to transfer data
   to newer versions of <productname>PostgreSQL</productname>, the output of
   <application>pg_dump</application> can be expected to load into
   <productname>PostgreSQL</productname> server versions newer than
   <application>pg_dump</application>'s version.  <application>pg_dump</application> can also
   dump from <productname>PostgreSQL</productname> servers older than its own version.
   (Currently, servers back to version 9.2 are supported.)
   However, <application>pg_dump</application> cannot dump from
   <productname>PostgreSQL</productname> servers newer than its own major version;
   it will refuse to even try, rather than risk making an invalid dump.
   Also, it is not guaranteed that <application>pg_dump</application>'s output can
   be loaded into a server of an older major version &mdash; not even if the
   dump was taken from