Re: handling unconvertible error messages

On Mon, 25 Jul 2016 10:43:44 -0400
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> Example: I have a database cluster initialized with
> --locale=ru_RU.UTF-8 (built with NLS). Let's say for some reason, I
> have client encoding set to LATIN1. All error messages come back
> like this:
>
> test=> select * from notthere;
> ERROR: character with byte sequence 0xd0 0x9e in encoding "UTF8" has
> no equivalent in encoding "LATIN1"
>
> There is no straightforward way for the client to learn that there is
> a real error message, but it could not be converted.

Really, situation is a bit worse. There is at least one case, where
error message comes unreadble to the client, even if encodings are
compatible.

I.e. if server default locale is ru_RU.UTF-8 and client requestes
encoding WIN1251 which is able to handle cyrillic.

If error occurs during processing of StartMessage protocol message,
i.e. client request connection to unexisting database,
ErrorResponse would contain message in the server default locale,
despite of client encoding being specified in the StartMessage.

If session is correctly established with such parameters, error
messages are displayed correctly.

I haven't yet investigatged if it is just delayed initialization of
backend locale system or backend is not yet forked at the time of
generation of this message and wrongly encoded message is sent by
postmaster.