hab den Cluster dann noch mal mit denselben Einstellungen auf dem neuen System angelegt, der pg_restore bricht dann aber immer noch mit der gleichen Meldung ab.
Habe dann auf What’s new in PostgreSQL 9.1 - PostgreSQL wiki gesehen, dass standard_conforming_string bei 9.1 auf on steht. Habe das auf dem neuen System auch so eingestellt und PostgreSQL neu gestartet, aber das Verhalten ist immer noch das gleiche.
Kann mir da jemand helfen? Hab schon gegoogelt, aber nur Sachen gefunden, die f�r PostgreSQL 8.0beta zutrafen.
An Deiner Stelle würde ich den Dump mal mit -Fc (nicht tar) erstellen, und zwar mit dem pg_dump des Zielsystems. Stimmt der Zeichensatz in der Shell, damit client_encoding beim Restore?
Ach ja, ohne --column-inserts würde es wahrscheinlich recht viel schneller gehen.
danke, werde es gleich testen, habe aber noch eine Frage bzgl. Zeichensatz in der Shell, damit ich es richtig verstehe:
die man-page vom pg_dump sagt:
-E encoding, --encoding=encoding
Create the dump in the specified character set encoding. By default, the dump is created in the database encoding. (Another way
to get the same result is to set the PGCLIENTENCODING environment variable to the desired dump encoding.)
die man-page vom pg_restore sagt bzgl. encoding gar nichts.
Soll ich also PGCLIENTENCODING bzw. den Parameter -E verwenden? Oder meintest Du die Variable LANG?
Nach langen Tests hier die überraschende Lösung: es liegt weder an der collation noch dem Wert von standard_conforming_string noch dem Format des Dumps (tar, custom, etc), sondern: der Parameter --column-inserts ist der Bösewicht!
Verstehe es zwar nicht, aber wenn 's geht (und dann auch noch schneller), soll 's mir recht sein!