Create Sequence

Moin,

ich bin immer noch dabei ein mit pg_dump erstelltes Backup in den gleichen Datenbankserver aber in eine andere Datenbank zurückzuspielen. Es ist ein PG 7.3.8 Server.

Wenn ich nun das pg_dump dieses Servers nehme, kann ich das Backup nicht zurückspielen.

Also habe ich mir die Sourcen zum 7.4.17 gezogen und übersetzt. Dann habe ich mit diesem pg_dump ein Backup erzeugt (pg_dump -d rt3 > rt3.out).

Wenn ich nun per psql dieses Backup zurückspielen möchte, bekomme ich direkt zu Beginn Fehlermeldungen:

psql:rt3.out:33: ERROR:  parser: parse error at or near "BY" at character 50
psql:rt3.out:41: ERROR:  Relation "attachments_id_seq" does not exist
psql:rt3.out:42: ERROR:  Relation "attachments_id_seq" does not existS

Es geht dabei um das Statement:

CREATE SEQUENCE queues_id_seqi INCREMENT BY 1 NO MAXVALUE NO MINVALUE CACHE 1;

Nun schein psql über dieses Statement zu stolpern. Wenn ich das Statement nun so ändere, geht es wieder:

CREATE SEQUENCE queues_id_seqi INCREMENT 1 CACHE 1;

Sind die Versionen so inkompatibel zueinander? Wie bekomme ich nun ein Backup wieder zurückgespielt. Ich weiß, das es eine alte Serverversion ist. Aber daran läßt sich nunmal nichts ändern.

Damit ich das richtig verstehe:

Du hast eine 7.3.x Datenbank. Ziehst mit einem pg_dump von 7.4.x ein Backup und möchtest dieses Backup in die 7.3.x Datenbank wieder einspielen?

Das wird nicht funktionieren, 7.4.x kennt aktuellere Features und das pg_dump Tool nutzt diese natürlich aus.

Tja, das siehst du richtig und ich hatte so was schon vermutet. Allerdings bekomme ich auf dem gleichen Weg - dann aber mit dem 7.3.x pg_dump - gar nichts zurückgespielt. Fehlermeldung suche ich gleich raus.

Den Tip mit der anderen Version kam hier aus dem Forum. Also hab ichs mal probiert. War dann wohl nix …

Ja, das war ich.

Wenn die Sequencen das einzigste sind, wo es Probleme gibt, dann ändere das. Ich vermute, daß das keinen Einfluß hat.
Ansonsten: nutze eine höhere Version, 7.3 ist IMHO nicht mehr supportet.

Andreas

Hallo Andreas,

Nein, es gibt noch mehr Probleme. Ich hab das Logfile aber schon gelöscht und weiß die Meldungen nicht mehr.

Mit der höheren Version meinst du dann den DB-Server?

Also
1.) mit pg_dump 7.4 ein Backup aus dem alten DB-Server 7.3.8 erstellen
2.) dieses Backup dann in einen neuen DB-Server 7.4.17 zurückspielen.

Das aufsetzen eines neuen PG Servers wollte ich eigentlich vermeiden. Aber wenns nicht anders geht :frowning:

Kann ich denn den neuen PG-Server parallel zum alten installieren? Das geht vermutlich nicht auf der gleichen Linux Kiste, oder? Die Version 7.4.17 hab ich schon übersetzt bekommen. Aber ich habe noch kein make -install gemacht.

Es hätte den Vorteil, daß z.B. 8.1 dank Memory Bitmap Index Scan bei komplexen Abfragen erheblich schneller ist.

Kann ich denn den neuen PG-Server parallel zum alten installieren? Das geht vermutlich nicht auf der gleichen Linux Kiste, oder? Die Version 7.4.17 hab ich schon übersetzt bekommen. Aber ich habe noch kein make -install gemacht.

Geht. Man muß halt aufpassen, daß unterschiedliche Datenverzeichnisse und ein anderer Port genutzt wird → damit also auch eine andere Config-Datei. Debian macht es z.B. auch so, wenn man ein Update macht.

Andreas

so, nun hab ich hier auch die Fehlermeldung beim Zurückspielen des 7.3.8 er Backups:

...
psql:rt3.out:209645: ERROR:  copy: line 33747, value too long for type character varying(100)
psql:rt3.out:209645: lost synchronization with server, resetting connection
...

Das Script läuft aber weiter durch. Ist die Frage, ob es nur dieser eine Insert ist, der das schief läuft!

Nur damit ich dich nicht falsch verstehe. Ich müsste also die neue Version so erstellen:

./configure --prefix=/usr/local/pgsql8.1 --with-pgport=xyz

Das Datenverzeichnis liegt dann ja automatisch unterhalb von /usr/local/pgsql8.1, oder?

Wir sind mitten in der Installation - vielleicht verschieben …

Ja, man kann das wohl auch reinkompilieren, ansonsten mittels Parameter bzw. Config-File.

Andreas