Ja, das stimmt schon; meine Antwort war nicht korrekt. Es ist ja auch immer ein client_encoding gesetzt. Wenn es nicht explizit gesetzt wurde, kommt es entweder von der Environment Variable PGCLIENTENCODING, von der “locale” der aufrufenden Shell oder vom am Server eingestellten Defaultwert.
Das heißt: der Client liest die Bytes aus der Datei aus, so wie sie sind, und interpretiert sie im Sinne des Client Encodings.
Ich vermute auch kein encoding Problem. Die Fehler treten auf, nachdem tausende von Zeilen innerhalb des COPY Bereichs erfolgreich verarbeitet wurden.
Liegt ggf. ein Problem beim Schreiben vor ? Der 2. Fehler (ungerade Byteanzal bei einem BLOB) deutet darauf hin, daß beim Schreiben “ein Byte” verloren geht. Das aber auch nach tausenden erfolgreich gelesener Zeilen innerhalb des COPY Bereichs.
Liegt hier ein Problem des Betriebsystems/Postgresql (Puffer, Puffergrenzen/-überlappung, Speichermedium per USB angebunden o.a.) vor ?
Ich gehe mal davon aus, dass pg_dump und pg_dumpall die gleichen Basisfunktionen zum dumpen der Datenbank verwenden. Ich habe mit dieser Konstellation (Speichermedium per USB angebunden) vor einigen Tagen erfolgreich eine Datenbank von ca. 900 GB Dumpfilegröße erstellt und erfolgreich ohne Fehler auf einen anderen Server übertragen.
Dump einzelner DBs mit pg_dump und separates einspielen funktioniert ohne Probleme. Bei der Verwendung von pg_dump all in der in der Doku beschriebenen Art treten die Probleme auf.
Ich werde das nach dem Erscheinen von Version 18.0 noch einmal versuchen. Dazu muss ich auf der Maschine erst mal Platz für das Dumpfile - erwartet 1,2-1,5 TB - schaffen und eine fest eingebaute Festplatte mit Linux verwenden.
Danach werden wir sehen ob sich der Fehler reproduzieren lässt oder ob es eines der großen Rätsel von Windows bleiben wird.
Klar ist das nicht unbedingt notwendig. Ich möchte aber wie bereits erwähnt noch einmal prüfen ob die von mir beschriebene Fehlersituation noch einmal auftritt.
Kein Problem - Dump bzw. Restore beauftragen und die Maschine machen lassen - ggf. über Nacht. Nachher das Fehlerprotokoll ansehen. Wenn wieder ein Fehler auftritt, dann kann ich versuchen Input für Laurenz zu liefern.
Ich habe jetzt mal den Brachialansatz ausprobiert. Ich habe mit pg_dumpall eine Instanz mit ca. 10 Datenbanken im plain Format gedumpt und dann wieder eingespielt.
Beim Dump und Wiedereinspielen unter Linux über Netzwerk traten keinerlei Fehler auf (Dumpfile 1,2 TB).
Das Thema wird ein ungelöstes Rätsel unter Windows bleiben.