Как это индексы ломаются?

SELECT uukey FROM t WHERE id = 1 выдает например xxx UPDATE t SET uukey = yyy WHERE id =1 Тот же селект выдаст ххх, но если вырубить индекс скан, то yyy

Окей, чо тогда это?

https://t.me/pgsql/474564 Снимите логи сессии, что ли.

Если бы можно было, я бы это сделал)

https://t.me/pgsql/303899

Если у Вас нет возможности применять никакие отладочные средства... может быть, этой проблемой должны заниматься не Вы (а тот, кто не даёт Вам такой возможности, например ;) )?

Сяп за токсичность. 5к строк заливать сюда смысла ноль. Проблему я описал. Если у вас идей, кроме как потешать своё эго нет, то спасибо вам! Других данных дать физически не могу. База локальная. Нет у нее доступа к сети. Никакого. Вообще. Версия пг 9.6

Похоже на битый индекс Попробуйте сделать reindex таблице

О как! Индексы у людей выше не ломаются! А тут оказывается ломаются

Реиндекс в транзакции не сделать, все происходит в одной транзакции

Слова "ломаются" и "сломанный" имеют катастрофически разный смысл.

Сделайте не в транзакции )

> 5к строк заливать сюда смысла ноль. 5k строк чего? Это там в одной транзакции столько statements? > Если у вас идей, кроме как потешать своё эго нет Причём тут моё эго?! Я Вам написал, что Вам нужно делать — но нет, вместо того все должны гадать, что там у вас происходит. > Никакого. Вообще. Тем не менее, хоть что-то (как-то) Вам показать (или рассказать) придётся, если не хотите, чтобы это превратилось в состязание "чей хрустальный шар лучше". ;) > Версия пг 9.6 Очень давно пора выбросить обновить, кстати.

Ну он становится сломанным после апдейта, до этих пор все окей и этого не заметно.

Незя, лог то в транзакции нужно записать

Обновитесь, проверьте железо.

Сейчас дядю в интернете почитаю в телеграмме и побежим всей тимой обновлять пг! Секунду!

Щас ты побежишь в другой чат. Это очень серьёзное предупреждение.

Кажется вы смешиваете теплое с мягким. Индекс - если он битый - после перестроения будет целым и работать четко. И при следующем вашем апдейте в транзакции - уже все будет работать хорошо.

Это официальная позиция сообщества PostgreSQL, для информации (это давно не поддерживаемая версия PostgreSQL). Если Вы с этой проблемой придёте в официальные mailing lists, то там скажут ровно то же самое (а проблему и разбирать не будут, почти наверняка).

Ярослав как -то вчера был абсолютно несогласен с вами :)

Я с этим не спорю, просто для чего было эти смешные картинки и язвить ну не ясно было. Я понимаю что я не дал кода и не дал аналайз и инфы с грошь дал, но это тоже не просто так. Старый легаси код тоже кто то поддерживает и этот кто то - я. Поэтому извиняюсь если задел, но я бился с этим ооочень долго,чтобы дойти до этой причины неправильных логов. И я ее описал. Если у кого то был похожий опыт, то буду рад его узнать. Если никто не сталкивался, то ладно.

Ну так по умолчанию считается, что с "железом" всё нормально, когда подобные вопросы задают... по крайней мере, об этом думают, обычно, в последнюю очередь. ;) Так что тут я согласен с @aggeisoft (хотя (судя по v9.6 в production), там может быть всякое).

Вы не описали почти ничего, извините (ни транзакций, ни statements, ни обработки ошибок в коде, ни конкретных результатов запросов). > Если никто не сталкивался, то ладно. Я сталкивался с похожим буквально сотни раз, и почти каждый раз причина была именно в том, что код написан некорректно.

Имел очень интересную проблему с год назад. Правда версия pg была 12.x (но последовательно обновляемая с версии 9.5 еще). Так вот - был битый уникальный индекс - который не был помечен как invalid и СУБД считала его вполне хорошим и рабочим - только при перестроении выяснилось - что есть дубли по полям в индексе. Дублей было немного, но пришлось сделать кучу работы - чтобы их убрать (без потери логической целостности данных). Проверить можно было так: Делаешь запрос который попадает в индекс - выдает 100 записей. Добавляешь псевдоусловие в фильтр (чтобы не сканировало по индексу) или выключаешь indexscan - выдает 102 записи

вероятно, был сбой носителя возможно были и др битые объекты

Идея с фильтром тоже пришла, буду ковырять. Спасибо!

Возможно - у БД была долгая история с кучей разных ЦОДов, аварий и прочего. Кроме того - все эти последовательные обновления с версии на версию - тоже могли сказаться. В момент воспроизведения проблемы - с железом все было впорядке

А тут "пахнет" тем, что кто-то работает с data_checksums = off. ;) Хотя, на самом деле, это мог быть и bug, но менее вероятно, мне кажется.

И вы абсолютно правы. Кластер изначально был без чексумм - и при обновлении через pg_upgrade их нельзя было включить. Только при обновлении через pg_dump