similar to <application>pg_dump</application> for specifying
    the database server to connect to and the user name to use. See
    the <xref linkend="app-psql"/> reference page for more information.
   </para>

   <para>
    Non-text file dumps should be restored using the <xref
    linkend="app-pgrestore"/> utility.
   </para>

   <para>
    Before restoring an SQL dump, all the users who own objects or were
    granted permissions on objects in the dumped database must already
    exist. If they do not, the restore will fail to recreate the
    objects with the original ownership and/or permissions.
    (Sometimes this is what you want, but usually it is not.)
   </para>

   <para>
    By default, the <application>psql</application> script will continue to
    execute after an SQL error is encountered. You might wish to run
    <application>psql</application> with
    the <literal>ON_ERROR_STOP</literal> variable set to alter that
    behavior and have <application>psql</application> exit with an
    exit status of 3 if an SQL error occurs:
<programlisting>
psql -X --set ON_ERROR_STOP=on <replaceable>dbname</replaceable> &lt; <replaceable>dumpfile</replaceable>
</programlisting>
    Either way, you will only have a partially restored database.
    Alternatively, you can specify that the whole dump should be
    restored as a single transaction, so the restore is either fully
    completed or fully rolled back. This mode can be specified by
    passing the <option>-1</option> or <option>--single-transaction</option>
    command-line options to <application>psql</application>. When using this
    mode, be aware that even a minor error can rollback a
    restore that has already run for many hours. However, that might
    still be preferable to manually cleaning up a complex database
    after a partially restored dump.
   </para>

   <para>
    The ability of <application>pg_dump</application> and <application>psql</application> to
    write to or read from pipes makes it possible to dump a database
    directly from one server to another, for example:
<programlisting>
pg_dump -h <replaceable>host1</replaceable> <replaceable>dbname</replaceable> | psql -X -h <replaceable>host2</replaceable> <replaceable>dbname</replaceable>
</programlisting>
   </para>

   <important>
    <para>
     The dumps produced by <application>pg_dump</application> are relative to
     <literal>template0</literal>. This means that any languages, procedures,
     etc. added via <literal>template1</literal> will also be dumped by
     <application>pg_dump</application>. As a result, when restoring, if you are
     using a customized <literal>template1</literal>, you must create the
     empty database from <literal>template0</literal>, as in the example
     above.
    </para>
   </important>

   <para>
    After restoring a backup, it is wise to run <link
    linkend="sql-analyze"><command>ANALYZE</command></link> on each
    database so the query optimizer has useful statistics;
    see <xref linkend="vacuum-for-statistics"/>
    and <xref linkend="autovacuum"/> for more information.
    For more advice on how to load large amounts of data
    into <productname>PostgreSQL</productname> efficiently, refer to <xref
    linkend="populate"/>.
   </para>
  </sect2>

  <sect2 id="backup-dump-all">
   <title>Using <application>pg_dumpall</application></title>

   <para>
    <application>pg_dump</application> dumps only a single database at a time,
    and it does not dump information about roles or tablespaces
    (because those are cluster-wide rather than per-database).
    To support convenient dumping of the entire contents of a database
    cluster, the <xref linkend="app-pg-dumpall"/> program is provided.
    <application>pg_dumpall</application> backs up each database in a given
    cluster, and also preserves cluster-wide data such as role and
    tablespace definitions. The basic usage of this command is:
<synopsis>
pg_dumpall &gt; <replaceable>dumpfile</replaceable>