Re: logfile character encoding - Mailing list pgsql-general

On 08/16/2014 12:26 PM, Redoute wrote:
> Hello,
>
> please help me with this problem: My postgreSQL logfiles generally are
> encoded in UTF-8, but some entries are in Windows-1252. The server
> status in pgAdmin III doesn't cope with this; it is unusable because of
> continuous error popups.

> log destination is configured as stderr, with logging collector on
> (default setup). So it may be one issue that stderr is written in 1252
> (not sure about that), but then why are most logfile entries encoded in
> UTF-8? Is only a part of all messages routed via stderr?
>
> Another idea is that the 1252 encodings may be related to pgAdmin III? I
> send almost all SQL via its query window.
>
> Windows 8.1
> PostgreSQL 9.3.5 64 bit
> pgAdmin 1.18.1
> database encoding UTF8
> all on the same PC, no multiple servers or database encodings involved
>
> Some examples of entries with 8 bit encoded chars (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
> ===
>
>
> and some entries with UTF8-encoded non ASCII chars:
> ===
> 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
> ===

Based on Google Translate I observed the following from the above.
The first batch of messages are entirely server related messages, either
start up or config file changes. The second batch are entirely query
based messages. This would seem to be the reverse of your suspicion that
sending queries through pgAdmin is changing the encoding to 1252. So
some questions:

Are you positive the database is UTF8?

Is there something setting the encoding different for a connection?

>
> Thanks, Redoute
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com