Re: 13.x, stream replication and locale(?) issues
От | Thomas Munro |
---|---|
Тема | Re: 13.x, stream replication and locale(?) issues |
Дата | |
Msg-id | CA+hUKGLM5=+qkUf7ZiwH_VPfrsSaxvRt47cp7YmFxTYDgNMQ1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | 13.x, stream replication and locale(?) issues ("Eugene M. Zheganin" <eugene@zhegan.in>) |
Ответы |
Re: 13.x, stream replication and locale(?) issues
|
Список | pgsql-general |
On Wed, Mar 1, 2023 at 12:09 AM Eugene M. Zheganin <eugene@zhegan.in> wrote: > 3) how do I fix it ? Should I take locale sources for ru_RU.utf8 on Linux and compile it on FreeBSD - will it help ? Out of curiosity (I'm not saying it's a good idea!), do you know if FreeBSD's localedef can compile glibc's collation definitions? In theory they are in a format standardised by POSIX... I suspect there may be extensions and quirks... At a wild guess, since the data you showed doesn't even look like it contains non-ASCII characters (it looks like machine readable identifiers or something, and perhaps its the sort order of '-' that is causing you trouble), so it might also be possible to use "ucs_basic" locale for that column and then all computers will agree on the sort order, but of course that doesn't address the more general problem; presumably you might also have Russian language text in your system too. As for ".utf8" vs ".UTF-8", which one is selected by initdb as the database default seems to be something that varies between Linux distributions, so I guess maybe the installers use different techniques for discovering and selecting default locale names. Unlike glibc, FreeBSD doesn't do any name mangling at all when mapping LC_COLLATE to a pathname to find the file, whereas glibc downcases and removes '-' so you can find both formats of name in the various places...
В списке pgsql-general по дате отправления: