Ich versuche einen Cluster mit einigen Datenbanken mittels pg_dumpall auf eine neue Majorversion zu übertragen. Als Test im Vorfeld habe ich den Cluster mittels pg_dumpall in eine Datei gesichert. Dann habe ich vesucht diesen erzeugten Dump (ca. 700 GByte - viele BLOBS/CLOBS) in einen leeren Cluster der gleichen PostgreSQL Version einzuspielen.
Hierbei zeigt das Logfile zahlreiche Fehler beim COPY Befehl (mehr Daten als Spalten, ungerade hexZiffern bei einem Blob) mit der Folge dass die Tabellen leer bleiben.
Ich habe testweise eine betroffene Tabelle mit pg_dump gedumpt und diesen in den neuen Cluster eingelesen. Hier trat keinerlei Problem auf. Alle Tabellenzeilen sind sichtbar.
Es handelt sich um eine Windows 11 Pro System, 64bit, 32 GB RAM. Beide Postgresql-Vesionen sind 17.5.
Hat jemand schon mal etwas ähnliches beobachtet ? Ich habe den Dump/Restore nach der Dokumentation durchgeführt (User/Passwort/Port/Host per Umgebungsvariable gesetzt).
Mich verwirrt “auf eine neue Majorversion” und dann “Beide Postgresql-Vesionen sind 17.5”
Wenn Du damit ein Upgrade machen willst, dann sollte der Dump mit dem pg_dump der neuen Version gemacht werden (wenn Du das auf dem gleichen Server machst, dann ist pg_upgradesowieso die bessere Wahl).
Wenn wirklich beide Versionen 17 sind, und pg_dump von der Version 17 verwendet wurde, dann finde ich das verhalten merkwürdig. Kann es sein, dass beim Einspielen Berechtigungen gefehlt haben, und Tabellen (oder Schemata oder Datenbanken) nicht angelegt wurden?
Ich will demnächst meine DB von 17.5 auf 18 (soll ja in den nächsten Tagen erscheinen) umstellen. Das plane ich mit pg_dumpall durchzuführen.
Da ich das bis jetzt noch nicht verwendet habe, wollte ich mit der 17.5 einen Testdurchlauf durchspielen. 17.5 Cluster per pg_dumpall dumpen und in einen leeren neuen Cluster der Version 17.5 einspielen. Im Idealfall sollten alle DBs + Berechtigungen + Tabelleninhalten + Views + Funktionen + Prozeduren im neuen Cluster vollkomen identisch sein.
Leider zeigt das Logfile beim Import die erwähnten Fehler. Es sind nur einige Tabellen betroffen. 99 % der Tabellen usw. sieht alles ok aus (inkl. grants, Berechtigungen usw.)
Es sieht so aus als ob der Dump von pg_dumpall an einigen Stellen fehlerhaft war. Z.B. wurde von psql beim Import gemeckert, dass ein falsches Format für numeric (“3r”) vorliegt. In dem Fall sieht es so aus als ob der Spaltentrenner “verschluckt” wurde. In anderen Fällen wurden mehr Daten als Spalten angemeckert. Das sieht so aus als ob der Zeilentrenner “verschluckt” wurde.
Schon seltsam, denn pg_dumpall sollte doch ein Dumpfile erstellen, welches syntaktisch korrekt ist und von psql der gleichen Version wieder eingelesen werden kann.
Hmm, klingt merkwürdig. Mal etwas aus der Luft gegriffen (da Windows): läuft ein Virenscanner? Wenn ja, versuch mal das Verzeichnis in dem der Dump erstellt wird davon auszunehmen.
Ich bin kein Fan von pg_dumpall, deswegen mache ich grundsätzlich Dumps mit pg_dump und “custom format” (-Fc)
Du kannst es ja mal (nur) mit der Datenbank bei der es scheitert, versuchen ob es dann klappt.
Ich mache “komplette” Backups immer mit pg_dumpall –globals-only um die Rollen/Benutzer zu bekommen, und dann für jede Datenbank ein pg_dump -Fc einzeln (kann man mit einer Batchdatei problemlos automatisieren)
Um das Problem festzunageln, wäre es wichtig, die Zeile im pg_dumpall zu finden, die den Fehler auslöst, sowie die Definition der entsprechenden Tabelle. Ein Encoding-Problem halte ich für unwahrscheinlich, weil im Dump-File client_encoding explizit gesetzt wird.
Hmm, das definiert doch “nur” das Encoding mit dem psql die Daten an den Server schickt? Aber nicht das Encoding mit dem psql die Datei zum Lesen öffnet, oder?
Genau. Damit das zu einem Problem führt, müßte jemand das Dump-File in ein anderes Encoding umwandeln, sodaß das SET client_encoding-Statement nicht mehr das richtige Encoding setzt.
Ich dachte eher an die Situation, dass bei pg_dump ein Encoding angegeben wurde (z.B. UTF-8), beim Aufruf von psql aber nicht. Dann liest psql mit Win1252 eine UTF-8 Datei - dabei können dann durchaus mal Zeichen verschluckt werden, was dann zu den Fehlern oben führen kann.
Interessant, das scheint wirklich zu funktionieren. Aber wie macht psql das, wenn es die Datei mit einem anderen Encoding geöffnet hat? Schließen und mit dem richtigen Encoding neu öffnen?
Man kann eine Datei nicht “mit einem Encoding öffnen”. PostgreSQL öffnet die Datei und liest die Daten in dem Encoding, in dem sie drinnen stehen. Dadurch, daß man client_encoding richtig einstellt, wandelt der Datenbankserver die Daten richtig ins Server-Encoding um.
Da habe ich wohl zu lange Java programmiert. Da muss man beim Öffnen einer Textdatei ein Encoding mit angeben, wenn man den Inhalt korrekt lesen möchte.
Aber irgendwie muss das Programm doch wissen wie viele Bytes ein Zeichen ergeben - und das hängt ja vom Encoding ab. Wenn ich also ein Single-Byte Encoding verwende, dann kriege ich 3 “Zeichen” wenn die Datei als UTF-8 gespeichert wurde, das “Zeichen” dort aber mit 3 Bytes codiert wurde.
Der Client muß nicht unbedingt wissen, wieviele Bytes ein Zeichen ergeben. Er liest einfach die Datei und schickt die SQL-Statements (oder die COPY-Daten) so, wie er sie findet, an den Server.
Aber psql muss das Skript doch “parsen” um die psql Kommandos (\echo oder ähnliche) zu erkennen. Dafür muss aber das Encoding der Datei bekannt sein, sonst kommt der Parser (oder zumindest der Lexer) doch in’s Stolpern. Oder übersehe ich da was?