Комментарии 4
Кстати, а не нарывались на проблему с индексами по строкам, если там есть специфические символы ?
Бывало, что если через физическую репликацию перегонять сервер с CentOS 7 и на CentOS 8, то все такие индексы просто начинали работать неправильно. Есть подозрение, что для сравнения строк PostgreSQL использует библиотеки ОС, и там по разному реализовано сравнение в разных ОС для некоторых символов...
Мы с таким не сталкивались, но я знаю о такой проблеме. Такие индексы нужно проверять перед миграцией. Этот момент очень хорошо освещен тут. По ссылке есть пример запроса, которым можно проверить поведение сортировки. Вот например как это выглядит у нас:
На Centos7
postgres@postgres=# WITH t(c) AS (
postgres@postgres(# VALUES('а'),('б'),('в'),('a'),('b'),('c'),('1'),('2'),('3')
postgres@postgres(# )
postgres@postgres-# SELECT string_agg(t.c,',' ORDER BY t.c) AS "default",
postgres@postgres-# string_agg(t.c,',' ORDER BY t.c COLLATE "ru-x-icu") AS "ru-x-icu"
postgres@postgres-# FROM t \gx
-[ RECORD 1 ]---------------
default | 1,2,3,a,b,c,а,б,в
ru-x-icu | 1,2,3,a,b,c,а,б,вА вот так тот же запрос выглядит на AlmaLinux8
postgres@postgres=# WITH t(c) AS (
postgres@postgres(# VALUES('а'),('б'),('в'),('a'),('b'),('c'),('1'),('2'),('3')
postgres@postgres(# )
postgres@postgres-# SELECT string_agg(t.c,',' ORDER BY t.c) AS "default",
postgres@postgres-# string_agg(t.c,',' ORDER BY t.c COLLATE "ru-x-icu") AS "ru-x-icu"
postgres@postgres-# FROM t \gx
-[ RECORD 1 ]---------------
default | 1,2,3,a,b,c,а,б,в
ru-x-icu | 1,2,3,а,б,в,a,b,cОбратите внимание, что на AlmaLinux8 при ru-x-icu сначала идет кирилица, что правильно, а на Centos7 там же идет латиница, что по моему мнению является багом. А вот почему этот баг проявляется, сложно сказать, в обоих базах провайдер сортировки ICU и поэтому должно бы работать одинаково. Может Ваше предположение и верно, о том, что в Centos7 хоть и написано, что используется ICU, но по факту может и libc использоваться.
Мы обычно просто после миграции, на всякий случай, перестраиваем индексы по строкам (благо их немного).
Кстати, еще один момент. Не сталкивались с тем, что в CentOS 8 начинаются какие-то проблемы при работе с большим количеством временных таблиц ? У меня несколько раз при миграции с CentOS 7 на CentOS 8 при большом количестве пользователей и соединений (1000+) висли запросы вида TRUNCATE t131 и ANALYZE t439. К сожалению, не было времени разбираться в причинах из-за жалоб пользователей и приходилось просто откатывать на CentOS 7 обратно.
Работа идет на ванильном PostgreSQL и там нет fast_trunc (да и там логика все-таки подразумевает транзакционность очистки временных таблиц). Единственная идея почему именно на CentOS 8 возникала проблема - это в том, что там как-то по другому реализована работа с файлами, и TRUNCATE тормозит на создании нового файла под временную таблицу на уровне операционной системы из-за того, что в каталоге оказывается под миллион файлов. Причем там был именно xfs, у которого известные проблемы с большим количеством мелких файлов, на ext4, к сожалению, проверить не получилось.
Миграция Postgrespro с Centos7 на AlmaLinux8. Как бонус — пара седых волос