Re: nls and server log

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: nls and server log
Date: 2014-12-29 22:39:07
Message-ID: 54A1D80B.10801@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/28/14, 2:56 AM, Craig Ringer wrote:
> On 12/25/2014 02:35 AM, Euler Taveira wrote:
>> Hi,
>>
>> Currently the same message goes to server log and client app. Sometimes
>> it bothers me since I have to analyze server logs and discovered that
>> lc_messages is set to pt_BR and to worse things that stup^H^H^H
>> application parse some error messages in portuguese.
>
> IMO logging is simply broken for platforms where the postmaster and all
> DBs don't share an encoding. We mix different encodings in log messages
> and provide no way to separate them out. Nor is there a way to log
> different messages to different files.
>
> It's not just an issue with translations. We mix and mangle encodings of
> user-supplied text, like RAISE strings in procs, for example.
>
> We really need to be treating encoding for logging and for the client
> much more separately than we currently do. I think any consideration of
> translations for logging should be done with the underlying encoding
> issues in mind.

Agreed.

> My personal opinion is that we should require the server log to be
> capable of representing all chars in the encodings used by any DB. Which
> in practice means that we always just log in utf-8 if the user wants to
> permit DBs with different encodings. An alternative would be one file
> per database, always in the encoding of that database.

How much of this issue is caused by trying to machine-parse log files? Is a better option to improve that case, possibly doing something like including a field in each line that tells you the encoding for that entry?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-12-29 22:48:29 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Previous Message Jeff Janes 2014-12-29 22:29:27 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}