Thread: BUG: Incorrect working with POSIX locale if database in UTF-8encoding

On 10/17/18 2:29 AM, Олег Самойлов wrote:
> I think this is a bug, because database encoding logging must work even 
> in this case. The main problem is with pacemaker module pgsqlms, which 
> launch pg_ctl in empty environment and thus with broken logging.

I suggest filing an issue here:

https://github.com/ClusterLabs/PAF/issues




-- 
Adrian Klaver
adrian.klaver@aklaver.com

Don’t agree. Pgsqlms just run pg_ctl with POSIX locale, this is not a bug. But unreadable messages when locale charset
don’tmatch database charset is bug of pg_ctl. When messages come from within connection all fine, why don’t do the same
formessages on start/stop? 

> 17 окт. 2018 г., в 15:13, Adrian Klaver <adrian.klaver@aklaver.com> написал(а):
>
> On 10/17/18 2:29 AM, Олег Самойлов wrote:
>> I think this is a bug, because database encoding logging must work even in this case. The main problem is with
pacemakermodule pgsqlms, which launch pg_ctl in empty environment and thus with broken logging. 
>
> I suggest filing an issue here:
>
> https://github.com/ClusterLabs/PAF/issues
>
>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com

On Wed, 17 Oct 2018 12:29:52 +0300
Олег Самойлов <splarv@ya.ru> wrote:

> There is not problem with systemctl, if system locale setted by localectl is
> the same as database locale. But, as I said, there is problem with pacemaker
> pgsqlms module. And I think this is incorrect behavior. Database may write in
> log messages in database locale, if this messages arises inside connection to
> this database. But common messages, such as messages on start cluster or
> errors on start cluster must written according to locale settings, and if
> locale empty (POSIX) such messages must be in english. And if messages not in
> english they must be visible as is, not as ‘???’. :) It works inside
> connection, why this does not work on start/stop?

It seems like POSIX support ASCII and some additional characters. So maybe the
character encoding used in the database is just incompatible with POSIX, ie.
POSIX does not support wide chars. As you can see, characters from ASCII table
are printed correctly.

=?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv@ya.ru> writes:
> [ postmaster's localized messages are printed as garbage if LANG is C or unset ]

I'm not quite convinced that this is a bug.  The reason it's misbehaving
is that in the postmaster process (and, probably, non-backend children)
LC_MESSAGES gets set to whatever you said in postgresql.conf, but LC_CTYPE
is never changed away from what it was in the postmaster's environment.
So if the prevailing environment setting is C/POSIX, gettext() throws up
its hands and substitutes "?" for non-ASCII characters, because it has
no idea which encoding to render them in.

This is sort of intentional, in that the environment LC_CTYPE ought to
reflect the "console encoding" that you're operating in; if you run your
terminal in say KOI8R, then you set LC_CTYPE=ru_RU.koi8r and messages
should get printed in the encoding the terminal is expecting.

We could maybe make a case for forcing gettext to use the encoding
implied by LC_MESSAGES if LC_CTYPE is C/POSIX, but I'm not really
convinced that there's anything principled about that.

On the other hand, the current behavior in this situation surely
isn't useful to anybody.  Arguably, gettext() is being pretty
unhelpful here, but I doubt we could get them to change.

Peter, any thoughts?

            regards, tom lane

I think correct behavior will be get the whole locale from postgresql.conf (like the backend processes do) or from
environment.It’s  a question, may be, from what place do take locale, but obviously from only one. But do not take
LC_TYPEfrom the one place (postgresql.conf), while LC_MESSAGES from other (environment). Te bug is here. 

> 18 окт. 2018 г., в 19:29, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
>
> =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv@ya.ru> writes:
>> [ postmaster's localized messages are printed as garbage if LANG is C or unset ]
>
> I'm not quite convinced that this is a bug.  The reason it's misbehaving
> is that in the postmaster process (and, probably, non-backend children)
> LC_MESSAGES gets set to whatever you said in postgresql.conf, but LC_CTYPE
> is never changed away from what it was in the postmaster's environment.
> So if the prevailing environment setting is C/POSIX, gettext() throws up
> its hands and substitutes "?" for non-ASCII characters, because it has
> no idea which encoding to render them in.
>
> This is sort of intentional, in that the environment LC_CTYPE ought to
> reflect the "console encoding" that you're operating in; if you run your
> terminal in say KOI8R, then you set LC_CTYPE=ru_RU.koi8r and messages
> should get printed in the encoding the terminal is expecting.
>
> We could maybe make a case for forcing gettext to use the encoding
> implied by LC_MESSAGES if LC_CTYPE is C/POSIX, but I'm not really
> convinced that there's anything principled about that.
>
> On the other hand, the current behavior in this situation surely
> isn't useful to anybody.  Arguably, gettext() is being pretty
> unhelpful here, but I doubt we could get them to change.
>
> Peter, any thoughts?
>
>             regards, tom lane