I guess that the issue is related to this setting in the postgresql.conf file:
lc_messages = 'Russian_Russia.1251' # locale for system error message
I tried chaning it to 'en_US.UTF-8' and all new message in the log file are in English and look good regardless of whether I view it in UTF-8 or ANSI encoding.
I don't know what ANSI stands for either but it goes first in the list of encodings in notepad++ Encodings menu.
I guess it refers to Windows-1251 in my case.
The English variant of the messed up message in the UTF8 section of the screenshot above is LOG: database system was shut down at ...
LOG: database system is ready to accept connections
All my databases have encoding=UTF8, collate=Russian_Russia.1251, ctype=Russian_Russia.1251
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > I suppose you have databases with the single-byte encoding amidst your > UTF8 ones. AFAIK the log file registers the log entries in the same > encoding that the database uses. Different databases can use different > encodings.
> That's pretty broken, but it's how it is.
Yeah, and it's not easy to improve on. If we tried to convert all log messages to the same encoding, which one would that be? (Please, no nonsense about UTF8 being a universal solution. The Japanese don't think so, for instance.)
Also, what do you do if you get an encoding conversion failure?
That's even before you get into implementation-dependent problems, like what to do early in process startup before the encoding conversion machinery is operational.
A more realistic idea might be to have separate log files for different encodings, though that has a bunch of management issues to solve as well.
