This is a multi-part message in MIME format.
--------------050905040004000102010108
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Hallo,
ich habe das Problem, dass wir einen Dump einer sehr umfangreichen
Datenbank anfertigen wollen. Nicht nur, dass pg_dump die Objekte nicht
in der richtigen Reihenfolge erstellt, es werden auch ab und zu
Sequenzen vergessen.
Bei kleineren Dumps korrigiert man das schnell noch per Hand, bei große=
n
Dumps ist das allerdings fast unmöglich. Gibt es eine andere,
zuverlässigere Methode?
Im 7.2'er Manual stand übrigens noch folgenden:
22.1.4. Caveats
pg_dump (and by implication pg_dumpall) has a few limitations which
stem from the difficulty of reconstructing certain information from
the system catalogs.
Specifically, the order in which pg_dump writes the objects is not
very sophisticated. This can lead to problems for example when
functions are used as column default values. The only answer is to
manually reorder the dump. If you created circular dependencies in
your schema then you will have more work to do.
For reasons of backward compatibility, pg_dump does not dump large
objects by default. To dump large objects you must use either the
custom or the TAR output format, and use the -b option in pg_dump.
See the reference pages for details. The directory contrib/pg_dumplo
of the PostgreSQL source tree also contains a program that can dump
large objects.
Please familiarize yourself with the pg_dump reference page.
Dieser Abschnitt wurde im aktuellen Manual entfernt, die Probleme
existieren jedoch auch bei PostgreSQL 8.2.
Viele Grüße,
Marc
--------------050905040004000102010108
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
Hallo,<br>
<br>
ich habe das Problem, dass wir einen Dump einer sehr umfangreichen
Datenbank anfertigen wollen. Nicht nur, dass pg_dump die Objekte nicht
in der richtigen Reihenfolge erstellt, es werden auch ab und zu
Sequenzen vergessen.<br>
<br>
Bei kleineren Dumps korrigiert man das schnell noch per Hand, bei
großen Dumps ist das allerdings fast unmöglich. Gibt es eine andere,
zuverlässigere Methode?<br>
<br>
Im 7.2'er Manual stand übrigens noch folgenden:<br>
<br>
<blockquote>
<div class=3D"SECT2">
<h2 class=3D"SECT2"><a name=3D"BACKUP-DUMP-CAVEATS">22.1.4. Caveats</a>=
</h2>
<p> <span class=3D"APPLICATION">pg_dump</span> (and by implication <spa=
n
class=3D"APPLICATION">pg_dumpall</span>)
has a few limitations which stem from the difficulty of reconstructing
certain information from the system catalogs. </p>
<p> Specifically, the order in which <span class=3D"APPLICATION">pg_dum=
p</span>
writes the objects is not very sophisticated. This can lead to problems
for example when functions are used as column default values. The only
answer is to manually reorder the dump. If you created circular
dependencies in your schema then you will have more work to do. </p>
<p> For reasons of backward compatibility, <span class=3D"APPLICATION">=
pg_dump</span>
does not dump large objects by default.<a name=3D"AEN19077"></a> To dump
large objects you must use either the custom or the TAR output format,
and use the <tt class=3D"OPTION">-b</tt> option in <span
class=3D"APPLICATION">pg_dump</span>. See the reference pages for
details. The directory <tt class=3D"FILENAME">contrib/pg_dumplo</tt> of
the <span class=3D"PRODUCTNAME">PostgreSQL</span> source tree also
contains a program that can dump large objects. </p>
<p> Please familiarize yourself with the <span class=3D"CITEREFENTRY"><=
span
class=3D"REFENTRYTITLE">pg_dump</span></span> reference page. </p>
</div>
</blockquote>
<br>
Dieser Abschnitt wurde im aktuellen Manual entfernt, die Probleme
existieren jedoch auch bei PostgreSQL 8.2.<br>
<br>
Viele Grüße,<br>
Marc<br>
<pre class=3D"moz-signature" cols=3D"72">
</pre>
</body>
</html>
--------------050905040004000102010108--
