Guten Abend,

ich habe große Probleme, ein mit pg_dump erzeugtes Backup zu
rekonstruieren, so dass auch die BLOBs enthalten sind. Die Tabelle wird
problemlos rekonstruiert, auch in den "BLOB"-Spalten steht noch der
OID-Verweis (das Restore wird mit Exitcode 0 fehlerfrei beendet). Sobald
ich jedoch die Daten extrahieren will, erscheint die Meldung, dass das
"large object with ... does not exist".
Ich habe schon viele Tipps aus Google und PostgreSQL-Archiven
ausprobiert (auch den pg_dump habe ich mit den verschiedenen
Kombinationen von Parametern ausprobiert), allerdings ohne Erfolg. Kann
es an der Datenbankgröße liegen? Ich habe auch versucht, erst nur das=

Schema zu rekonstruieren und anschließend die Daten. Die Tabelle hat
3.2Mio Datensätze, die BLOBs sind nur wenige KB groß (das
PostgreSQL-Datenverzeichnis ist 6,9 GB groß, der Dump liegt bei 2,1GB).=

Im Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large
objects" auslagern würde.
Ich verwende PostgreSQL 8.1 auf Windows.
Kennt jemand eine zuverlässige Methode, wie man Tabellen mit BLOBs
dumpen und wieder einlesen kann?

Vielen Dank im Voraus für jeden Hinweis,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

am 11.06.2006, um 23:31:14 +0200 mailte Ulrich Cech folgendes:
> Guten Abend,
>
> ich habe große Probleme, ein mit pg_dump erzeugtes Backup zu
> rekonstruieren, so dass auch die BLOBs enthalten sind. Die Tabelle wird=


Vorweg: ich hab mit BLOB's in der DB keine Erfahrungen.


> Parametern ausprobiert), allerdings ohne Erfolg. Kann es an der
> Datenbankgröße liegen?

eher nicht.


> rekonstruieren und anschließend die Daten. Die Tabelle hat 3.2Mio
> Datensätze, die BLOBs sind nur wenige KB groß (das
> PostgreSQL-Datenverzeichnis ist 6,9 GB groß, der Dump liegt bei 2,1GB=
). Im

Das würde mich massiv stutzig machen. Entweder hast Du sehr viel Platz
mit toten Tupels belegt oder durch viele Indexe etc., aber ich vermute
mal eher:



> Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large
> objects" auslagern würde.

Zum Schluß? Im Dump sollte als letzte Zeilen stehen:

--
-- PostgreSQL database dump complete
--

Prüfe, ob das bei Dir der Fall ist. Ansonsten ist der Dump
unvollständig. Ich vermute mal wild, daß PG Deine BLOBS in einer
TOAST-Table auslagert und diese nicht mit gesichert ist. Warum auch
immer, vielleicht eine 2 GByte-Beschränkung des Filesystems?



> Ich verwende PostgreSQL 8.1 auf Windows.

*Seufz*. Aber ich soll ja kein Windoze-Bashing mehr machen...


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hi

Ich hab eine DB mit BLOBS mit

pg_dump -b -C -Ft -f dbname.tar

in ein Archiv geschrieben und mit

pg_restore -v -C -d template1 dbname.tar

auf einem anderen Rechner wieder rekonstruiert. Ohne Problem.
Allerdings war das eine PG 7.x und ein Linux-Rechner, unter win habe
ich es noch nie probiert. Die Blobs kamen als .dat-Dateien mit.

Gruesse
Conni
--
http://pgsql.info | http://postgresql.de | http://pgfakt.de
Telefon: 07127 80 961

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hallo Cornelia,

ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB
immer die folgende Fehlermeldung:
pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen: N=
o
such file or directory

Ich habe langsam das Gefühl, dass ein Dump unter Windows bei größer=
en
Datenbanken nicht korrekt funktioniert, denn ich konnte eine kleine
Datenbank mit zwei BLOBs zumindest im Custom-Format problemlos dumpen
und rekonstruieren.

Trotzdem vielen Dank,
Ulrich

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am 16.06.2006, um 8:26:26 +0200 mailte Ulrich Cech folgendes:
> Hallo Cornelia,
>
> ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB im=
mer
> die folgende Fehlermeldung:
> pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen:=
No
> such file or directory

Wilder Schuß ins blaue: keine Umgebungsvariable TEMP oder TMP, kein
Verzeichnis C:\temp oder sowas in der Richtung.

>
> Ich habe langsam das Gefühl, dass ein Dump unter Windows bei größ=
eren
> Datenbanken nicht korrekt funktioniert, denn ich konnte eine kleine

Ich hab schon seit 10 Jahren das Gefühl, daß Windows zum arbeiten vö=
llig
ungeeignet ist...



Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Hallo Andreas,


>>Parametern ausprobiert), allerdings ohne Erfolg. Kann es an der
>>Datenbankgröße liegen?
>>
>>
>
>eher nicht.
>
>
Merkwürdigerweise hat ein Dump und Restore mit einer kleinen Test-DB
inkl. BLOBs problemlos funktioniert...


>>Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large
>>objects" auslagern würde.
>>
>>
>
>Zum Schluß? Im Dump sollte als letzte Zeilen stehen:
>
>--
>-- PostgreSQL database dump complete
>--
>
>
Ich leite die Ausgabe von pg_dump in eine Datei, als letzter Eintrag
steht dort "sichere Kommentare für large objects". Dies steht ebenfalls=

als letzter Eintrag in meiner kleinen TestDB, mit der ein Dump/Restore
einwandfrei funtioniert.

Ich verwende jetzt folgenden dump-Befehl, der auch erfolgreich durchläu=
ft:
pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -b -D -v -f
<backup-filename> <dbname>

Allerdings erhalte ich beim Restore die Fehlermeldung:
pg_restore.exe -i -h localhost -p 5432 -U postgres -d <dbname> -a
--disable-triggers -v <backup-filename>

....
pg_restore: restoring large object data
pg_restore: [archiver] could not write to large object (result:
4294967295, expected: 797)
pg_restore: *** aborted because of error
Prozess beendet mit Exitcode 1.


Zumindest sieht es so aus, als wären die BLOBs im Dump enthalten (das
suggeriert die Meldung).
Ich habe auch mal ein FULL VACUUM laufen lassen, was keinen Unterschied
gebracht hat.


>>Ich verwende PostgreSQL 8.1 auf Windows.
>>
>>
>
>*Seufz*. Aber ich soll ja kein Windoze-Bashing mehr machen...
>
:-)) Ich hatte noch überlegt zu erwähnen, bitte jegliche Kommentare
dahingehend zu vermeiden, da mir die Linux-Umgebung auch lieber wäre ;-=
))

Vielleicht liegt es tatsächlich daran, dass pg_dump unter Windows und
größeren Datenbanken nicht zurecht kommt.

Trotzdem vielen Dank.
Ulrich



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hallo,

>>ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB im=
mer
>>die folgende Fehlermeldung:
>>pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen:=
No
>>such file or directory
>>
>>
>
>Wilder Schuß ins blaue: keine Umgebungsvariable TEMP oder TMP, kein
>Verzeichnis C:\temp oder sowas in der Richtung.
>
>
Gute Idee! Ich habe gerade nachgeschaut, ist leider alles vorhanden
(aber es könnte natürlich ein Berechtigungsproblem sein, dass der Use=
r
keine Schreibrechte auf das TMP-Verzeichnis hat...), dass werde ich mal
prüfen....
Das war es leider auch nicht...

>Ich hab schon seit 10 Jahren das Gefühl, daß Windows zum arbeiten vö=
llig
>ungeeignet ist...
>
>
>
Ich befürchte, mir wird unter Windows nichts andere übrig bleiben als=

das komplette "data"-Verzeichnis zu sichern...

Danke und Gruß,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

am 16.06.2006, um 9:02:44 +0200 mailte Ulrich Cech folgendes:
> >Zum Schluß? Im Dump sollte als letzte Zeilen stehen:
> >--
> >-- PostgreSQL database dump complete
> >--
> >
> Ich leite die Ausgabe von pg_dump in eine Datei, als letzter Eintrag st=
eht
> dort "sichere Kommentare für large objects". Dies steht ebenfalls als=

> letzter Eintrag in meiner kleinen TestDB, mit der ein Dump/Restore
> einwandfrei funtioniert.

Mmh. Ich hab mit BLOB's noch nix gemacht.


>
> Ich verwende jetzt folgenden dump-Befehl, der auch erfolgreich durchlä=
uft:
> pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -b -D -v -f
> <backup-filename> <dbname>
>
> Allerdings erhalte ich beim Restore die Fehlermeldung:
> pg_restore.exe -i -h localhost -p 5432 -U postgres -d <dbname> -a
> --disable-triggers -v <backup-filename>
>
> ...
> pg_restore: restoring large object data
> pg_restore: [archiver] could not write to large object (result: 4294967=
295,
> expected: 797)
> pg_restore: *** aborted because of error
> Prozess beendet mit Exitcode 1.

Kann es sein, daß Du damit ein Problem hast:

pg_dump has a few limitations:


Members of tar archives are limited to a size less than 8 GB. (This=
is an inher-
ent limitation of the tar file format.) Therefore this format cannot =
be used if
the textual representation of any one table exceeds that size. The to=
tal size of a
tar archive and any of the other output formats is not limited, excep=
t possibly by
the operating system.


Aber eigentlich eher nein, weil Du verwendest ja -Fc und das ist kein tar=
..

Die Meldung 'could not write' könnte irgendwie auf Probleme mit
Filesystem, Rechten, Dateigröße oder sowas hindeuten. Ich weiß es n=
icht.


Kannst Du nicht mal ein Linux-System testweise hochziehen und dort den
Dump reinziehen?

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Hallo,

>Mmh. Ich hab mit BLOB's noch nix gemacht.
>
>
>
Ist doch kein Problem, bin ja über jeden Hinweis/Grashalm :-) etc.
dankbar...

> Die Meldung 'could not write' könnte irgendwie auf Probleme mit
>
>Filesystem, Rechten, Dateigröße oder sowas hindeuten. Ich weiß es =
nicht.
>
>
>Kannst Du nicht mal ein Linux-System testweise hochziehen und dort den
>Dump reinziehen?
>
>
>
Ja, das werde ich demnächst mal versuchen, obwohl das dann schwierig
wird, einen Linux-Server in einer reinen Windows-Serverlandschaft
durchzusetzen ;-))... aber vielleicht wäre das mal ein erster Einstieg.=
...

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Freitag, 16. Juni 2006 09:02 schrieb Ulrich Cech:
> pg_restore: restoring large object data
> pg_restore: [archiver] could not write to large object (result:
> 4294967295, expected: 797)
> pg_restore: *** aborted because of error

pg_dump ist immer sehr geheimnisvoll über den eigentlichen Grund für =
Fehler.
Das pg_dump in 8.2 ist da besser, also bei Bedarf vielleicht das mal
probieren.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hallo,

>pg_dump ist immer sehr geheimnisvoll über den eigentlichen Grund für=
Fehler.
>Das pg_dump in 8.2 ist da besser, also bei Bedarf vielleicht das mal
>probieren.
>
>
>
ich glaube langsam immer mehr, dass es tatsächlich an der Dateigröß=
e
unter Windows liegt. Bisher sind alle Versuche, einen Dump zu erzeugen
und wieder einzulesen, fehlgeschlagen, zumindest mit der 7GB DB (eine
kleine Testdatenbank hat funktioniert).
Seit kurzem (der Dump hat mittlerweile eine Größe von etwas über 2G=
B)
erscheint jetzt sogar beim pg_dump-Aufruf folgende Meldung:
....
pg_dump: sicherer Large Objects
pg_dump: [Custom-Archivierer] Warnung: erwartete Dateiposition stimmt
nicht mit ftell überein -- benutze ftell
pg_dump: sichere Kommentare für Large Objects

Dann muss ich wohl mal auf die Version 8.2 warten und bis dahin
versuchen, zumindest einmal die Woche den DB-Server herunterzufahren und
das komplette "data"-Verzeichnis sichern, so dass es wenigstens ein
bißchen "Backup" gibt ;-)...

Danke und Gruß,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Hallo,

als kurzer Zwischenstand folgende Situation:
Ich habe am Wochenende auf 8.1.4-1 upgedatet. Der Fehler beim pg_dump
(...ftell...) erscheint immer noch, auch beim pg_restore erscheint eine
Fehlermeldung (..."invalid argument..."; leider habe ich verpasst, die
Ausgabe komplett zu notieren). Anschließend bricht der Restore-Vorgang
ab, es sieht aber so aus, als passiere dies beim Rekonstruieren der
Kommentare zu den BLOBs (wo faktisch nichts zu rekonstruieren ist).

Zumindest, und das ist die positive Entwicklung, sind die BLOBs
vorhanden und können wieder extrahiert werden, so dass mit dem Dump
jetzt tatsächlich eine Sicherung der Daten vorliegt.

Ich bin schon sehr auf die nächste Version gespannt, vielleicht
verschwinden dann die restlichen Fehlermeldungen auch noch.

Nochmals vielen Dank für alle Hilfestellungen.

Ulrich


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ulrich Cech wrote:
> Hallo,
>
> als kurzer Zwischenstand folgende Situation:
> Ich habe am Wochenende auf 8.1.4-1 upgedatet. Der Fehler beim pg_dump
> (...ftell...) erscheint immer noch, auch beim pg_restore erscheint eine
> Fehlermeldung (..."invalid argument..."; leider habe ich verpasst, die
> Ausgabe komplett zu notieren). Anschließend bricht der Restore-Vorgan=
g
> ab, es sieht aber so aus, als passiere dies beim Rekonstruieren der
> Kommentare zu den BLOBs (wo faktisch nichts zu rekonstruieren ist).
>
> Zumindest, und das ist die positive Entwicklung, sind die BLOBs
> vorhanden und können wieder extrahiert werden, so dass mit dem Dump
> jetzt tatsächlich eine Sicherung der Daten vorliegt.
>
> Ich bin schon sehr auf die nächste Version gespannt, vielleicht
> verschwinden dann die restlichen Fehlermeldungen auch noch.

http://archives.postgresql.org/pgsql-committers/2006-05/msg0 0284.php

ist wohl das problem mit den COMMENTS der BLOBS - und wird in 8.1.5
behoben sein ...


Stefan

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Hallo Stefan,

anbei endlich die komplette Ausgabe vom pg_restore mit einigen Fehlern
(u.a. bei den COMMENTS der BLOBs).
Was mir vor allem Sorgen macht sind die Fehlermeldungen bezüglich
Inhaltsverzeichniseintrag u.s.w. Ein "Extraktionstest" hat jedoch ein
BLOB problemlos erstellen können, d.h. die BLOBs scheinen jetzt wirklic=
h
rekonstruiert worden zu sein.

************************************************************ *************=
*******
pg_restore.exe -i -h localhost -p 5432 -U postgres -d archive
--disable-triggers -v "c:\_myplace\a4a.backup"
pg_restore: verbinde mit der Datenbank zur Wiederherstellung
pg_restore: [Archivierer (DB)] Fehler in Phase INITIALIZING:
pg_restore: [Archivierer (DB)] could not execute query: ERROR: invalid b=
yte
sequence for encoding "UTF8": 0xe46973
Command was: --
-- PostgreSQL database dump
--

-- Started on 2006-07-03 01:00:00 Westeuropäische Normalzeit

SET client_encoding =3D 'UTF8';
pg_restore: erstelle SCHEMA public
pg_restore: erstelle COMMENT SCHEMA public
pg_restore: erstelle PROCEDURAL LANGUAGE plpgsql
pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 253; 2=
612
16386 PROCEDURAL LANGUAGE plpgsql
pg_restore: [Archivierer (DB)] could not execute query: ERROR: language
"plpgsql" already exists
Command was: CREATE PROCEDURAL LANGUAGE plpgsql;
pg_restore: erstelle DOMAIN lo
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 207; 1=
247
16403 DOMAIN lo postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: type "lo"
already exists
Command was: CREATE DOMAIN lo AS oid;
pg_restore: erstelle FUNCTION autoinc()
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 15; 12=
55
16406 FUNCTION autoinc() postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"autoinc" already exists with same argument types
Command was: CREATE FUNCTION autoinc() RETURNS "trigger"
AS '$libdir/autoinc', 'autoinc'
LANGUAGE c;
pg_restore: erstelle FUNCTION lo_manage()
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 14; 12=
55
16405 FUNCTION lo_manage() postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"lo_manage" already exists with same argument types
Command was: CREATE FUNCTION lo_manage() RETURNS "trigger"
AS '$libdir/lo', 'lo_manage'
LANGUAGE c;
pg_restore: erstelle FUNCTION lo_oid(lo)
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 13; 12=
55
16404 FUNCTION lo_oid(lo) postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"lo_oid" already exists with same argument types
Command was: CREATE FUNCTION lo_oid(lo) RETURNS oid
AS $_$SELECT $1::pg_catalog.oid$_$
LANGUAGE sql IMMUTABLE STRICT;
pg_restore: erstelle TABLE archivemodel
pg_restore: Wiederherstellung der Daten von Tabelle
=BBarchivemodel=AB
pg_restore: Wiederherstellung der Large-Object-Daten
pg_restore: 3903641 Large Objects wiederhergestellt
pg_restore: Wiederherstellung der Daten von Tabelle =BBBLOB COMMENTS=AB
pg_restore: [Custom-Archivierer] Fehler beim Suchen in Datei: Invalid
argument
pg_restore: *** abgebrochen wegen Fehler

Prozess beendet mit Exitcode 1.
************************************************************ *************=
*******


Danke und Gruß,
Ulrich




Stefan Kaltenbrunner wrote:

> http://archives.postgresql.org/pgsql-committers/2006-05/msg0 0284.php
>
>ist wohl das problem mit den COMMENTS der BLOBS - und wird in 8.1.5
>behoben sein ...
>
>
>Stefan
>
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings