pg_restore bricht mit could not execute query: ERROR: unterminated quoted string ab

Hallo,

folgendes Problem:

  • habe einen dump von PostgreSQL 9.0.3 (OpenSUSE 11.4)
  • wurde erstellt mit /usr/bin/pg_dump --blobs --column-inserts --format=tar ims10db > ims10.tar
  • will diesen Dump auf einer anderen Maschine unter OpenSUSE 12.1 (PostgreSQL 9.1.1) mit pg_restore -e -d ims10db -Ft ims10.tar wiederherstellen
  • kriege dann aber folgenden Fehler:

pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 3245; 0 4364359 TABLE DATA abstract_guideline audimex
pg_restore: [Archivierer (DB)] could not execute query: FEHLER: Zeichenkette nicht abgeschlossen bei �’Werden Informationsbroschuren an Kunden und Vermittl�
ZEILE 6: …lverhaltensregeln - Vorschriften Anlageberatung’, 'Werden In…
^
Command was: INSERT INTO abstract_guideline (id, sort_order, name, description_text, topic_id, content_area_id, checklist_logic_id, audit…

Dachte zuerst, es k�nnte an collation/lc_type liegen:
altes System:
psql -l|pcregrep ‘template|ims10db|^ postgres’|column -t
ims10db | audimex | UTF8 | de_DE.utf8 | de_DE.utf8 |
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
template1 | postgres | SQL_ASCII | C | C | postgres=CT/postgres +



neues System:
psql -l|pcregrep ‘template|ims10db|^ postgres’|column -t
ims10db | audimex | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
postgres | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
template0 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres +
template1 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres +

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.

Danke im Voraus

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.


Andreas

Hallo Andreas,

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?

Probier es einfach aus, ich hatte solche Fehler noch nicht, daher sind meine persönlichen Erfahrungen damit auch eher gering …


Andreas

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!

Danke für die Hilfe!



Okay.

Welche Version?

Kannst Du bitte ein nachvollziehbares Testcase vorbereiten, damit man einen (reproduzierbaren) Bug hat, den man den Entwicklern geben kann?


Andreas