PostgreSQL "кортеж уже обновлен сам"

Наша база данных, кажется, сломана, обычно она использует около 1-2% процессора, но если мы запустим некоторые дополнительные бэкэнд-услуги, которые делают запросы UPDATE и INSERT для таблицы строк 10M (около 1 запроса за 3 секунды), все идет в ад (в том числе CPU увеличивается с 2% до 98% использования).

Мы решили отладить, что происходит, запустите VACUUM и ANALYZE, чтобы узнать, что неправильно с db, но...

production=# ANALYZE VERBOSE users_user;
INFO:  analyzing "public.users_user"
INFO:  "users_user": scanned 280 of 280 pages, containing 23889 live rows and 57 dead rows; 23889 rows in sample, 23889 estimated total rows
INFO:  analyzing "public.users_user"
INFO:  "users_user": scanned 280 of 280 pages, containing 23889 live rows and 57 dead rows; 23889 rows in sample, 23889 estimated total rows
ERROR:  tuple already updated by self

мы не можем завершить ANALYZE на ЛЮБОЙ из таблиц и не смогли найти никакой информации об этой проблеме. Любые предложения, что может быть неправильным?

 PostgreSQL 9.6.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit

Дополнительная информация по запросу:

Возможно, у вас поврежден pg_class

SELECT * FROM pg_class WHERE relname = 'users_user';

Выход: https://pastebin.com/WhmkH34U

Итак, первое, что нужно сделать, - выгнать все остальные сеансы и попробовать снова

Нет дополнительных сеансов, мы сбросили всю БД на новый сервер тестирования, проблема все еще возникает, нет клиентов, подключенных к этой БД

Ответ 1

Я бы порекомендовал вам запустить сервер со следующими параметрами перед поиском дублированных строк:

enable_indexscan = off
enable_bitmapscan = off
ignore_system_indexes = on

Если ваш сервер вышел из строя, индексы могут находиться в другом состоянии табличных данных. Это происходит, например, когда повреждение влияет на видимость транзакции (pg_clog). Затем найдите дублированную строку в pg_class или pg_statistic как указано в комментариях.

Вы также можете попытаться очистить pg_statistic. Сначала запустите сервер с:

allow_system_table_mods = on

А затем выпустите TRUNCATE TABLE и ANALYZE после этого:

--Cleaning pg_statistic
TRUNCATE TABLE pg_catalog.pg_statistic;
--Analyze entire database
ANALYZE VERBOSE;

Если проблема в pg_statistic, этого должно быть достаточно.