Добрый день, подскажите, а существует ли возможность появление записей-призраков? У

меня проблема, что в таблицу не инсертится запись duplicate key value violates unique constraint "statistic_pk"
Хотя я проверил, в таблице таких записей с такими ключами нет. Как такое может быть?

Битый индекс возможно.

Это как? И что с этим делать, не подскажите?

Либо неправильный код на клиенте. В общем — да, при нормальном функцыонировании сервера такое невозможно.

Для начала, проверить. set enable_index_scan on/off Сделать выборку используя индекс и без использования индекса. Сравнить результаты. Ключевое слово explain analyse

Использова reindex table statistic - не помогло сейчас попробую сделать как вы сказали

Для начала — проверить. Проделать выборку этой записи через indexscan и seqscan, убедиться, что есть расхождение. Затем, если действительно есть — то зависит от того, насколько важны вам данные. Если и фиг с ними — то привести таблицу (основной heap) к правильному состоянию, сделать reindex. Есои важны — остановить систему, сделать дамп, перелить на резервный сервер, проконтролировать цэлостность, потом с первым начать выяснять — нет ли аппаратных проблем или ошыбок конфигурацыи...

Сначала надо точно проверить. А то может вы не в той базе проверяете?

В норме такое может быть только в конкурентных транзакциях, по идее. А остальные варианты — какой-то corruption, да. :(

> Есои важны — остановить систему, сделать дамп, И выбросить его, если действительно важна корректность данных. ;( Т.е. в таких случаях приходится "признавать" потерю всех данных от последнего корректного состояния, такие дела.

set enable_seqscan = on; Seq Scan on statistic (cost=0.00..145011.93 rows=4031993 width=16) (actual time=0.018..855.330 rows=4031993 loops=1) Planning Time: 0.105 ms Execution Time: 1091.099 ms set enable_seqscan = off; Index Only Scan using statistic_pk on statistic (cost=0.43..175058.44 rows=4031993 width=16) (actual time=0.348..1228.734 rows=4031993 loops=1) Heap Fetches: 340263 Planning Time: 0.165 ms Execution Time: 1480.862 ms Запрос был по ключу explain analyze select loan_id, statistic_date from loans.statistic; Или мне следовало сделать какой-то специфичный запрос?

Вам нужно было проверить конкретный дубликат (взяв данные из сообщения об ошибке). Подобное недавно обсуждали, кстати: https://t.me/pgsql/318912

Надо ещё выполнить запрос без explain, чтобы результат увидеть. А так всё правильно и если дело в индексе, вы получите разный результат.

Ну, это просто чушь: обычно если корректность данных важна — то их можно достаточно достоверно сверить на корректность с какими-то резервными источниками. И это обычно дешэвле, чем терять данные с последнего бэкапа (при том, что после его врсстановления его корректность опять, разумеется, придётся проверять).

У меня же составной индекс, к сожалению, я не знаю точно какое значение у одного из компонентов, но знаю выборку, в которой он присутствует. Я могу составить запрос с loan_id ANY() and statistic_date = конкретное_значение?

Тут explain analyze нафиг не нужэн, только explain (чтобы подтвердить правильный метод поиска), и сами результаты — чтобы выяснить, с каким методом проблема.

ну сгруппируйте по pk и посмотрите count'ы большие единицы для каждого ключа (с индекс онли сканом и seq scan'ом соответственно)

> Ну, это просто чушь: обычно если корректность данных важна — то их можно достаточно достоверно сверить на корректность с какими-то резервными источниками. Это вопрос мнения — "достаточно достоверно" может вылиться в существенные потери, тем не менее. > И это обычно дешэвле, Смотря в какой области / с какими базами.

Подождите, Вы же писали: > duplicate key value violates unique constraint "statistic_pk" > Хотя я проверил, в таблице таких записей с такими ключами нет. Как такое может быть? Так что я не совсем понимаю, в чём проблема это сделать. > Я могу составить запрос с loan_id ANY() and statistic_date = конкретное_значение? Да составляйте как угодно — важно выбрать по тем условиям (значениям полей), которые приводят к ошибке.

Как минимум нет ни одной записи на statistic_date = '2020-08-06 00:00:00' Соответственно записей по ключу вообще нет

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

сам код вставки записей покажите)))

на клиенте?

Вы этого не проверили. Прочитайте то сообщение, которое я ранее цитировал.

из psql например