Export von Postgres 8.1.8 in 7.4.6

Hallo zusammen!

Ich bin mit Postgres bislang wenig vertraut und würde mich über etwas Unterstützung freuen. :slight_smile:

Ich beabsichtige, eine 50 MB große Postgres-DB (Version 8.1.8) in eine DB auf einem anderen Server (7.4.6) zu übertragen. Leider steht mir pg_dump nur auf dem neuen Server zur Verfügung. Dafür kann ich jedoch phpPgAdmin auf beiden Server nutzen. Dennoch scheint ein Export und Import nicht zu klappen, was vermutlich auf die unterschiedlichen Versionen zurückzuführen ist (es kommen Fehler wie “dump.sql:13: ERROR: cannot cast type text to regclass” oder “relation ‘XXXX’ does not exist”).

Hat jemand einen Tipp für mich?

Danke!
Dirk

Ja. Update die 7.4 auf 8.2.

Andreas

Dem kann ich mir eigentlich nur anschliessen. Abwärtskompatibel ist PostgreSQL nicht und du wirst viel manuelle Handarbeit in die Geschichte stecken müssen.

hallo zusammen!

leider habe ich erfahren, dass ein upgrade der von postgres auf 8.2 nicht möglich ist, da dies zu viele änderungen im system mit sich bringen würde (managed server). :astonished: nun habe ich ein echtes problem. gibt es irgendeine möglichkeit, die datenbank z.b. zunächst in eine andere db umzuwandeln (mysql?), um letztlich wieder eine postgres-db im format 7.4.6 zu erhalten?

falls nicht, welche änderungen sind vor allem zu machen, damit die db auf der version 7.4.6 läuft?

danke für eure antworten!
dirk

Hi,

also den Schritt über MySQL etc würd ich nicht machen. Da handelst du dir nur noch mehr Probleme ein.

Es kommt auf die Datenmenge an. Evtl. kannst du die Tabellen per Hand anlegen. Natürlich nur, wenn du nicht tausende Triggers etc. da mit dran hängen hast sonst dauert das ewig. Wenn du jedoch die Tabellenstruktur hast kannst du eventuell mit einen Export in eine CSV-Datei und dann wieder zurück in Postgres weiter kommen.

Ansonsten einfach probieren, den Dump einzuspielen und jeden Fehler ausbesser. Was aber nicht gerade ein schnelles Verfahren ist :confused:

cu tb.

Unwahrscheinlich

falls nicht, welche änderungen sind vor allem zu machen, damit die db auf der version 7.4.6 läuft?

Das kommt drauf an, wieviel Features genutzt werden, die es in der 7.4 nicht gibt. Die reinen Tabellen mit ihren Daten ist wahrscheinlich das kleinste Problem. Problematischer dürften da schon eher z.B. Funktionen sein, die vielleicht das Dollar-Quoting nutzen oder Funktionsaufrufe, die es in 7.4 nicht gibt. Du kannst nur versuchen, von der bestehenden DB einen ASCII-Dump zu machen und diesen einzuspielen. Bei jedem Fehler, der auftritt, dann halt mit $EDITOR sich drum kümmern. Viel Spaß :wink:

Andreas

das irrwitzige ist, dass die db vorher in der version 7.4.6 lief und anschließend upgegraded wurde. vielleicht ist das aber auch ein vorteil, denn dadurch sollten keine funktionen der version 8.1.8 genutzt werden.

die db-struktur scheint übrigens übernommen worden zu sein. lediglich der daten-import bringt eine menge fehler. kann ich den csv-export mit pgphpadmin machen oder bietet sich hierfür auch pg_dump an? gibt es evtl. andere tools, die besser mit den großen datenmengen zurecht kommen?

danke!
dirk

Dann sollten die Chancen nicht soooo schlecht sein…

die db-struktur scheint übrigens übernommen worden zu sein. lediglich der daten-import bringt eine menge fehler.

Welche? Hint: nur der ersten Fehler ist wichtig, der Rest (oft) nur Folgefehler.

kann ich den csv-export mit pgphpadmin machen oder bietet sich hierfür auch pg_dump an? gibt es evtl. andere tools, die besser mit den großen datenmengen zurecht kommen?

danke!
dirk

pg_dump ist das Mittel der Wahl.

Andreas

Hallo Dirk,

hast du den Import schon gelöst? Ich stehe vor demselben Problem - Wobei bei mir schon einige Tabellen erst gar nicht angelegt werden. Das Ganze hört sich übrigens nach Hetzner Managed Server an… stimmts?
Ich schätze, dass es funktionert, wenn man den Dump in zwei Teile teilt (wie schon hier vorgeschlagen):

1 - Struktur
2 - Daten (evtl. als CSV)

und den ersten Teil mit einem Editor so anpasst, dass keine inkompatiblen SQL-Anweisungen verwendet werden. Nur müsste ich wissen, welche das sind…
Nun, ich habe auch den Support von Hetzner dazu angeschrieben, mal sehen, ob die eine Lösung haben.

Vielleicht gibt es spezielle Parameter für pg_dump, die eine gewisse Abwärts-Kompatibiltät bieten?

Ich habe nun den Dump 1 (Nur Struktur) eingespielt und sukzessiv alle Anweisungen entfernt, die Fehlermeldungen verursachten, als da waren:

SET standard_conforming_strings = off;
SET escape_string_warning = off;
SET default_tablespace = '';
SET default_with_oids = false;

Dann folgende Syntax angepasst, denn CREATE TABLE kann man nicht entfernen - Dann fehlt ne Tabelle und nix geht mehr ;):

CREATE TABLE exampletable (
    id integer DEFAULT nextval('exampletable_id_seq'::regclass) NOT NULL,

::regclass kennt Postgres 7.4 anscheinend nicht, also einfach enfernt:

CREATE TABLE exampletable (
    id integer DEFAULT nextval('exampletable_id_seq') NOT NULL,

Folgende Anweisung habe ich einfach entfernt, obwohl ich mir unsicher bin, ob anschliessend die Datenbank wie gewünscht funktionier. Sie verknüpft die Sequenz fest mit der referenzierenden Tabellenspalte:

ALTER SEQUENCE exampletable_id_seq OWNED BY exampletable.id;

Das war’s - Danach konnte ich den Dump fehlerfrei einspielen. Für Teil 2 (Daten) komme ich gleich nochmal wieder…

Teil 2 besteht lediglich aus endlos vielen INSERTs. Vorangestellt waren einige SET-Parameter, aber die konnte ich nach demselben Prinzip wie bei Teil 1 säubern.

Jetzt ist alles sauber drin.
Die Methode kann ich weiterempfehlen.