У меня есть таблица с 85% мертвых строк, что доставляет мне проблемы. Я выполнил VACUUM (VERBOSE) MY_TABLE
в соответствии с этим ответом SO и согласно к результатам, ни один активный сеанс в настоящее время не сдерживает мой горизонт xmin (поэтому я не вижу, какой сеанс я мог бы завершить, чтобы автовакуум удалил мертвые строки).
Результаты VACUUM (VERBOSE) MY_TABLE
были такими:
...
CPU: user: 0.01 s, system: 0.01 s, elapsed: 0.04 s.
INFO: "my_table": found 69454 removable, 364950 nonremovable row versions in 41903 out of 82105 pages
DETAIL: 165590 dead row versions cannot be removed yet, oldest xmin: 3914663626
There were 10532004 unused item pointers.
Skipped 3 pages due to buffer pins, 39715 frozen pages.
...
Затем, выполнив этот запрос:
SELECT pid, datname, usename, state, backend_xmin
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY age(backend_xmin) DESC;
Вышло:
pid | datname | usename | state | backend_xmin
-------+----------+-----------------+--------+--------------
16664 | my_table | ¤ | active | 3914835133
30837 | my_table | my_user | active | 3915292658
...
Поэтому я не вижу ни одного сеанса с минимальным значением xmin, равным 3914663626
.
Я также попробовал два других запроса из этого ответа SO: один для подготовленных транзакций и для слотов репликации, и оба не дали строк.
Что еще может удерживать vacuum
от удаления этих мертвых строк?
(Если вам нужен полный вывод VACUUM (VERBOSE) MY_TABLE
, дайте мне знать, это около 30 строк.)
pg_cancel_backend
, но в моем случае нет. Я опубликовал результаты запроса, показывающие все активные сеансы с их xmin, и там ни один активный сеанс не имеет того же xmin, что и тот, о котором сообщает автоматическая очистка. - person Daniel   schedule 26.06.2019