Home Explore Blog CI



postgresql

13th chunk of `doc/src/sgml/ref/pg_dumpall.sgml`
d905701d9b1b559034ea769fe3446a18c54a399b8791db220000000100000cd3
 locale and encoding) that they had in the source cluster.
   Without the option, those databases will retain their existing
   database-level properties, as well as any pre-existing contents.
  </para>

  <para>
   If <option>--with-statistics</option> is specified,
   <command>pg_dumpall</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> on each database after restoring from a dump
   file to ensure optimal performance.  You can also run <command>vacuumdb -a
   -z</command> to analyze all databases.
  </para>

  <para>
   The dump script should not be expected to run completely without errors.
   In particular, because the script will issue <command>CREATE ROLE</command>
   for every role existing in the source cluster, it is certain to get a
   <quote>role already exists</quote> error for the bootstrap superuser,
   unless the destination cluster was initialized with a different bootstrap
   superuser name.  This error is harmless and should be ignored.  Use of
   the <option>--clean</option> option is likely to produce additional
   harmless error messages about non-existent objects, although you can
   minimize those by adding <option>--if-exists</option>.
  </para>

  <para>
   <application>pg_dumpall</application> requires all needed
   tablespace directories to exist before the restore;  otherwise,
   database creation will fail for databases in non-default
   locations.
  </para>

  <para>
   It is generally recommended to use the <option>-X</option>
   (<option>--no-psqlrc</option>) option when restoring a database from a
   <application>pg_dumpall</application> script to ensure a clean restore
   process and prevent potential conflicts with non-default
   <application>psql</application> configurations. Additionally, because
   the <application>pg_dumpall</application> script may
   include <application>psql</application> meta-commands, it may be
   incompatible with clients other than <application>psql</application>.
  </para>
 </refsect1>


 <refsect1 id="app-pg-dumpall-ex">
  <title>Examples</title>
  <para>
   To dump all databases:

<screen>
<prompt>$</prompt> <userinput>pg_dumpall &gt; db.out</userinput>
</screen>
  </para>

  <para>
   To restore database(s) from this file, you can use:
<screen>
<prompt>$</prompt> <userinput>psql -X -f db.out -d postgres</userinput>
</screen>
   It is not important which database you connect to here since the
   script file created by <application>pg_dumpall</application> will
   contain the appropriate commands to create and connect to the saved
   databases.  An exception is that if you specified <option>--clean</option>,
   you must connect to the <literal>postgres</literal> database initially;
   the script will attempt to drop other databases immediately, and that
   will fail for the database you are connected to.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <para>
    Check <xref linkend="app-pgdump"/> for details on possible
    error conditions.
  </para>
 </refsect1>

</refentry>

Title: pg_dumpall: More Notes, Tablespace Requirements, and Examples
Summary
This section continues with notes on pg_dumpall, covering harmless errors during CREATE ROLE, the necessity of pre-existing tablespace directories, and the recommendation to use the -X option with psql for clean restores. It also includes examples of dumping all databases and restoring from the resulting file, highlighting the importance of connecting to the 'postgres' database initially when using the --clean option. Finally, it refers to pg_dump for details on possible error conditions.