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

Question

Кажется, что наша база данных повреждена, обычно она использует около 1-2% процессорного времени, но если мы запустим некоторые дополнительные серверные службы, выполняющие запросы UPDATE и INSERT для таблицы 10M строк (около 1 запроса в 3 секунды), все будетчерт возьми (включая увеличение загрузки процессора с 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

Мы не смогли завершить АНАЛИЗ ЛЮБЫХ таблиц и не смогли найти никакой информации по этой проблеме.Любые предложения, что может быть не так?

 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

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

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

Answer 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, этого должно быть достаточно.