Re: Upgrading locale issues

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Upgrading locale issues
Дата
Msg-id CAH2-WzkZ5KLy60zR9QBS-dWsGADeUSgsm=1SjdpKBZ2qktiqdg@mail.gmail.com
обсуждение исходный текст
Ответ на Upgrading locale issues  (rihad <rihad@mail.ru>)
Ответы Re: Upgrading locale issues  (Thomas Munro <thomas.munro@gmail.com>)
Re: Upgrading locale issues  (rihad <rihad@mail.ru>)
Список pgsql-general
On Mon, Apr 29, 2019 at 7:45 AM rihad <rihad@mail.ru> wrote:
> Hi. Today we run pg_ctl promote on a slave server (10.7) and started
> using it as a master. The OS also got upgraded FreeBSD 10.4 -> FreeBSD
> 11.2. And you guessed it, most varchar indexes got corrupted because
> system local changed in subtle ways. So I created the extension amcheck
> and reindexed all bad indexes one by one. Is there any way to prevent
> such things in the future? Will switching to ICU fix all such issues?

Not necessarily, but it will detect the incompatibility more or less
automatically, making it far more likely that the problem will be
caught before it does any harm. ICU versions collations, giving
Postgres a way to reason about their compatibility over time. The libc
collations are not versioned, though (at least not in any standard way
that Postgres can take advantage of).

> The problem with it is that ICU collations are absent in pg_collation,
> initdb should be run to create them, but pg_basebackup only runs on an
> empty base directory, so I couldn't run initdb + pg_basebackup to
> prepare the replica server. I believe I can run the create collation
> command manually, but what would it look like for en-x-icu?

It is safe to call pg_import_system_collations() directly, which is
all that initdb does. This is documented, so you wouldn't be relying
on a hack.

-- 
Peter Geoghegan



В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Query not producing expected result
Следующее
От: Mark Zellers
Дата:
Сообщение: Migrating an application with Oracle temporary tables