такие ограничения? Или возможен баг с репликацией? Ни кто не сталкивался с таким?
это может произойти если "сломались" индексы и в таблицу можно добавить дубликаты. Лечится через REINDEX, а произойти могло если менялись системные либы (libicu в первую очередь)
Это в самом лучшем случае (вариант с glibc, https://wiki.postgresql.org/wiki/Locale_data_changes ). Скорее всего — это просто corruption, и надо искать причину ("железо", скорее всего) и заниматься recovery.
Полечить попробуем, спасибо! Маловероятно, что менялись системные библиотеки, так как крупных обновлений ПО не было с момента появления этой таблицы. Хотя... Железо клиента и мы туда не имеем доступа, произойти могло что угодно.
Вы начните с \d и т.д., всё же — вдруг Вам повезло (к примеру, CREATE INDEX CONCURRENTLY теоретически может оставить после своего аварийного завершения недостроенный (invalid) index с существующими дубликатами ну и т.п.).
Этот индекс появился вместе с таблицей около года назад и с тех пор не индекс, ни таблица не изменялись. Данные там вспомогательные, на бизнес-логику не влияют, поэтому далеко не сразу заметили наличие дубликатов.
у меня была "похожая проблема" месяца 3 назад. Причина - апгрейд ОС (изменение системных либ). Вылечилось через реиндекс. тут: https://t.me/pgsql/307852 там есть ссылка на скрипт для проверки индексов
О, отлично. Спасибо!
А по вашему опыту, часто такое бывает? Есть ли смысл в коде обрабатывать такие ситуации? С учётом того, что ПО ставится в закрытые контуры клиентов и не всегда есть шанс быстро обнаружить проблему.
в коде такое не поймать, имхо. И это чревато другими проблемами. Тут только делать реиндекс и "запретить" обновление системных либ (в первую очередь icu).
Обсуждают сегодня