PostgreSQL "tupla ya actualizada por sí mismo"

postgresql-9.6

Question

Nuestra base de datos parece estar dañada, normalmente utiliza aproximadamente el 1-2% de la CPU, pero si ejecutamos algunos servicios backend adicionales haciendo consultas de ACTUALIZACIÓN e INSERTA para la tabla de filas de 10M (aproximadamente 1 consulta por 3 segundos) todo irá al infierno (incluido CPU aumento de 2% a 98% de uso).

Hemos decidido depurar lo que está pasando, ejecutar VACÍO y ANALIZAR para saber qué está mal con db, pero ...

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

no podemos finalizar ANALIZAR en NINGUNA de las tablas y no hemos podido encontrar ninguna información sobre este problema. ¿Alguna sugerencia que puede estar mal?

 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

Información adicional según lo solicitado en los comentarios:

Tal vez tienes un pg_class corrupto

SELECT * FROM pg_class WHERE relname = ''users_user'';

Salida: https://pastebin.com/WhmkH34U

Entonces, lo primero que debe hacer es expulsar todas las demás sesiones e intentarlo de nuevo.

No hay sesiones adicionales, hemos volcado toda la base de datos en el nuevo servidor de prueba, el problema aún ocurre, no hay clientes conectados a esta base de datos

Answer 1

Le recomiendo que inicie el servidor con los siguientes parámetros antes de buscar filas duplicadas:

enable_indexscan = off
enable_bitmapscan = off
ignore_system_indexes = on

Si su servidor falla, los índices podrían estar en un estado diferente de los datos de la tabla. Esto sucede cuando la corrupción afecta la visibilidad de la transacción ( pg_clog ), por ejemplo. Luego busque una fila duplicada en pg_class o pg_statistic como se mencionó anteriormente.

También puedes intentar limpiar pg_statistic . Primero inicie el servidor con:

allow_system_table_mods = on

Y luego emitir una TRUNCATE TABLE y ANALYZE después:

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

Si el problema está en pg_statistic, esto debería ser suficiente.