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_TYPE from the one place (postgresql.conf), while LC_MESSAGES f
=?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= 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_MESSAG
On Wed, 17 Oct 2018 12:29:52 +0300
Олег Самойлов 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
> l
Don’t agree. Pgsqlms just run pg_ctl with POSIX locale, this is not a bug. But
unreadable messages when locale charset don’t match database charset is bug of
pg_ctl. When messages come from within connection all fine, why don’t do the
same for messages on start/stop?
> 17 окт. 2018 г., в 15:13,
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://git
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.
Let me explain on examples.
Empty databases:
-bash-4.2$ psql -p 5433 -l
