Zeichenkodierung Logfiles

Konfiguration & Verwaltung Konfiguration
1

Hallo,

bitte helft mir bei folgendem Problem: Meine PostgreSQL-Logfiles sind generell in UTF 8 kodiert, aber manche Einträge in Windows 1252. Der “Server-Status” von pgAdmin III stolpert über diese Kodierungsfehler, ist wegen fortlaufender Fehler-Popups unbenutzbar.

Ich habe verschiedene Diskussionen zu solchen Themen gefunden, z. B. PostgreSQL: BUG #5800: "corrupted" error messages (encoding problem ?) , verstehe aber Ursache und ggf. Abhilfe leider nicht.

Als log destination ist stderr konfiguriert, mit logging collector on (Standardwerte). Ein Faktor wird wohl sein, dass stderr standardmäßig in 1252 kodiert ist, aber warum kommen die meisten Meldungen dann richtig an? Läuft nur ein Teil der Meldungen über stderr?

Hängen die falschen Einträge evtl. auch mit pgAdmin III zusammen? Ich schicke praktisch alle SQL-Anweisungen über das Query-Fenster.

Windows 8.1
PostgreSQL 9.3.5 64 bit
pgAdmin 1.18.1
Datenbankkodierung UTF8
alles auf dem gleichen Rechner, es geht nicht um unterschiedliche Server oder Datenbankkodierungen

hier einige Beispiele für Einträge mit 8-Bit-Zeichen (Windows 1252):

2014-08-13 09:37:32 CEST LOG: Datenbanksystem wurde nicht richtig heruntergefahren; automatische Wiederherstellung läuft
2014-08-14 10:34:46 CEST LOG: Parameter „autovacuum“ auf „off“ gesetzt
2014-08-14 10:34:46 CEST LOG: Autovacuum-Launcher fährt herunter
2014-08-14 10:51:52 CEST TIPP: Erhöhen Sie eventuell den Konfigurationsparameter „checkpoint_segments“.
2014-08-14 14:32:43 CEST LOG: Parameter „fsync“ auf „off“ gesetzt
2014-08-14 14:32:43 CEST LOG: Parameter „full_page_writes“ auf „off“ gesetzt
2014-08-14 14:32:43 CEST LOG: Parameter „checkpoint_segments“ auf „128“ gesetzt

und hier einige Einträge mit UTF8-kodierten Nicht-ASCII-Zeichen:

2014-08-14 09:16:20 CEST FEHLER: Syntaxfehler bei „DROPT“ bei Zeichen 1
2014-08-14 09:16:48 CEST FEHLER: NULL-Wert in Spalte „id“ verletzt Not-Null-Constraint
2014-08-14 09:16:48 CEST DETAIL: Fehlgeschlagene Zeile enthält (null, 5).
2014-08-14 09:56:41 CEST TIPP: Konnte keine beste Kandidatfunktion auswählen. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.
2014-08-14 17:21:33 CEST FEHLER: „g“ ist keine bekannte Variable bei Zeichen 79
2014-08-14 17:21:33 CEST TIPP: Keine Funktion stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.
2014-08-14 17:21:33 CEST FEHLER: Relation „relation“ existiert nicht bei Zeichen 74
2014-08-14 19:05:46 CEST FEHLER: Spalte „ways.id“ muss in der GROUP-BY-Klausel erscheinen oder in einer Aggregatfunktion verwendet werden bei Zeichen 34
2014-08-14 19:28:08 CEST WARNUNG: Spalte „source“ hat Typ „unknown“
2014-08-14 19:28:08 CEST FEHLER: Spaltenverweis „id“ ist nicht eindeutig bei Zeichen 49
2014-08-14 20:19:51 CEST FEHLER: kann Sicht mpways nicht löschen, weil andere Objekte davon abhängen
2014-08-14 20:19:51 CEST DETAIL: Sicht mplines hängt von Sicht mpways ab
Sicht mpgeoms hängt von Sicht mplines ab
2014-08-14 20:19:51 CEST TIPP: Verwenden Sie DROP … CASCADE, um die abhängigen Objekte ebenfalls zu löschen.
2014-08-14 20:19:51 CEST FEHLER: Relation „mpways“ existiert bereits

2

Ist das Problem nun (mithilfe der Mailingliste :wink: ) gelöst?

3

Nicht gelöst, höchstens besser verstanden: PostgreSQL erstellt beim Starten einen Hauptprozess, auch “Postmaster” genannt. Bei Verbindungen durch Clients wird dann je Verbindung ein neuer Prozess gestartet. Jeder Prozess schreibt eigene Einträge in die Logdatei.

Die zusätzlichen Prozesse schreiben Logeinträge in der Kodierung der jeweiligen Datenbank, also bei einer Standardinstallation UTF-8. Der Postmaster lässt sich aber nicht überzeugen, in UTF-8 zu schreiben.

Die Einstellung für den Postmaster wird, normalerweise während der Installation, über das Programm initdb gesetzt. Die Einstellung ist nur über ein gültiges Locale möglich (http://de.wikipedia.org/wiki/Locale), es wird dann in Windows das zugehörige ANSI-Encoding genutzt. ANSI-Encodings sind aber immer 8Bit-Zeichensätze. Unicode bzw. UTF-8 ist eben kein ANSI und unter Windows auch kein Bestandteil irgendeines gültigen Locales (warum sollte es auch?).

Es gibt in dem Zusammenhang noch die Konfigurationsvariable lc_messages, die unterliegt aber offenbar derselben Einschränkung.

Hier meine Anfrage in der Mailingliste: http://thread.gmane.org/gmane.comp.db.postgresql.general/182932

Danke,
Redoute