pg_dump invalid memory alloc request size 4294967293

Hallo Leute,

kann mir evtl. jemand bei folgendem Problem helfen?

Ich muss eine Datenbank von Windows XP mit Postgres 8.2 nach Win 7 und Postgres 9.x umziehen. Leider scheitert es am Backup der Datenbank, den ich über PgAdmin auszuführen versuche!
Folgende Fehlermeldung bekomme ich beim Sichern einer Tabelle:

pg_dump: Fehlermeldung vom Server: ERROR: invalid memory alloc request size 4294967293
pg_dump: Die Anweisung war: COPY public.trainingsergebnis (trainingsergebnis_id, kundentp_id, machine_id, class_id, erstellt_am, template_name, summe, mandant_id, kunden_id, erstellt_am_datum, erstellt_am_zeit, bereichs_id, nutzung) TO stdout;
pg_dump: *** abgebrochen wegen Fehler

Was kann das sein und was kann ich machen, um die Daten zu sichern?

Nachtrag:
Ich habe schon den data-Verzeichnis auf einem anderen PC eingespielt, bekomme aber den gleichen Fehler.

http://postgresql.nabble.com/ERROR-invalid-memory-alloc-request-size-4294967293-td3327025.html

Das könnte ein Hinweis auf eine korrupte Tabelle sein. Funktioniert ein select * von der Tabelle?
Warum läuft da so alte Software, sowohl XP als auch PG 8.2 sind nicht mehr supportet. Habt ihr andere aktuelle Backups?

Ein Select mit Limit 100 funktioniert einwandfrei.
Sobald ich kein Limit angebe, bekomme ich folgenden Fehler:

ERROR: invalid memory alloc request size 4294967293
SQL Status:XX000

Die Tabelle enthält laut PgAdmin 3909230 Zeilen.

Hier müsste ich die Kunden Fragen, warum diese nicht unsere neuere Software einsetzen. Die wollten diese erst jetzt einsetzen und auf einen Windows 7 umziehen, was aber wegen dem Fehler nicht funktioniert.
Die anderen Backups sind leider auch nicht vollständig.

Das alles bestätigt den Verdacht, daß da, z.B. aufgrund Festplattenfehler oder so, die Daten korrupt sind. Evtl. bekommt ihr mit LIMIT und OFFSET und viel Geduld zumindest einen Zeil der Daten aus der Tabelle.

PS.: warum betreibt man PostgreSQL auf einem Destop-System? An wen darf ich denn ein Angebot für eine professionel gehostete Lösung durch unseren Vertrieb schicken lassen?

Welche 8.2 ist das denn genau? (das kannst Du mit einem select version(); anzeigen)
Vielleicht ist es ja ein Bug in der 8.2, der in einem späteren Minor-Release behoben wurde. Ein Upgrade von 8.2.x nach 8.2.y kann man ohne Aufwand durch Austauschen der Binaries machen. Wenn das also kein 8.2.23 ist, dann würde ich als erste versuchen das zu aktualisieren.

Das eigentliche Problem wird aber sein diese alte Version noch irgendwo zu bekommen.
Hier ist ein Archiv älterer Versionen: http://olex.openlogic.com/packages/postgresql/

Die Software wird nur im internen Netzwerk (öfters nur auf einem PC) verwendet. Bei vielen Kunden ist wegen des Datenschutzes nicht mal ein Internetzugang auf diesen PCs erlaubt! Viele Kunden installieren die Software selbst ohne den Administrator, so dass denen ein Linux ein Fremdwort ist.

Ich versuche mal die Zeilen zu finden, die evtl. defekt seien könnten.

Das hat leider nichts gebracht!

Ich habe versucht, die defekten Zeilen zu finden, aber es gibt wohl keine.
Alle Daten können mit Select abgerufen werden, sobald es eine Begrenzung auf ca. 1.600.000 Datensätze gibt. Bei 1.700.000 Datensätzen kommt schon der Fehler.

Dann kannst Du ja die Datensätze bis 1.600.000 und dann (vielleicht) wieder ab 1.700.000 holen. Vielleicht kannst das sogar weiter eingrenzen, 1650000? Je nach Größe der Rows stecken natürlich mehrere in einer Page, Du könntest da evtl. mit der ctid-Spalte noch arbeiten. Falls die Daten wichtig waren…

Lösung!

Die Tabelle, die den oben genannten Fehler bringt, scheint doch irgendwie defekt zu sein. Die Daten der Tabelle können aber Blockweise mit SELECT abgerufen werden.
Um eine Datensicherung der Datenbank durchzuführen, wurde folgendes durchgeführt:

  1. Die defekte Tabelle blockweise mit dem COPY-Befehl sichern (3.910.000 Datensätze):
copy (select * from tabelle where id >0 and id<=1500000 ) to 'c:\temp\tabelle_1.bin' with binary
copy (select * from tabelle where id >1500000 and id<=3000000 ) to 'c:\temp\tabelle_2.bin' with binary
copy (select * from tabelle where id >3000000 ) to 'c:\temp\tabelle_3.bin' with binary
  1. Alle Daten der Tabelle mit DELETE löschen.
  2. Die Datenbank sichern.
  3. Die Datenbank auf dem neuen Server wiederherstellen.
  4. Mit dem COPY-Befehl die Tabellendaten wiederherstellen:
copy tabelle from 'c:\temp\tabelle _1.bin' with binary
copy tabelle from 'c:\temp\tabelle _2.bin' with binary
copy tabelle from 'c:\temp\tabelle _3.bin' with binary

Die Wiederherstellung konnte auch testweise auf dem Postgres 8.2 in eine neue Datenbank wiederhergestellt werden. Die Daten der defekten Tabelle konnten dann vollständig mit einem SELECT-Befehl ohne Beschränkung aufgerufen werden!

Sehr schön!