🛠️ В логах появилось предупреждение о XID wraparound. Почему это не обычный VACUUM?
Артефакт:
WARNING: database "billing" must be vacuumed
within ... transactions
База пока работает, поэтому предупреждение легко отложить.
Но wraparound связан не с размером таблицы и не только с dead tuples.
PostgreSQL использует ограниченное циклическое пространство transaction ID. Старые версии строк нужно вовремя замораживать, чтобы после оборота XID они не выглядели как версии «из будущего».
Важно различать:
очистка dead tuples → повторное использование места
freeze → защита от XID wraparound
Даже почти статичная таблица может нуждаться в freeze.
С чего начать диагностику:
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;
datfrozenxid — не средний возраст строк. Его удерживает самое старое отношение внутри базы.
После этого ищут таблицу или TOAST с максимальным возрастом relfrozenxid.
Одного факта «VACUUM запускался» недостаточно. Нужно проверить:
— снизился ли age(relfrozenxid);
— завершился ли vacuum;
— не был ли он отменён;
— не находится ли старый XID в TOAST;
— не мешают ли долгие транзакции или prepared transactions;
— как быстро система расходует XID;
— насколько близко значение к настройкам конкретной версии и системы.
Anti-wraparound autovacuum запускается даже при отключённом обычном autovacuum. Отменять его как «неудобную фоновую уборку» опасно.
Если предупреждения игнорировать, PostgreSQL перестанет назначать новые XID. Записывающие операции начнут завершаться ошибками, хотя read-only-нагрузка ещё может работать.
Типичная ошибка:
anti-wraparound autovacuum грузит диск
→ отменим
→ запустим обычный VACUUM потом
Так можно сократить оставшийся запас XID.
Не начинайте с VACUUM FULL, массового VACUUM FREEZE или изменения freeze-параметров без анализа версии, таблиц и окна обслуживания.
Вывод: риск wraparound нужно искать до аварийного сообщения — по возрасту datfrozenxid, relfrozenxid, TOAST-отношений и динамике расходования XID.
Сохраните набор признаков, по которым риск XID wraparound нужно искать до аварийного сообщения.
🔹🔹🔹🔹
Артефакт:
WARNING: database "billing" must be vacuumed
within ... transactions
База пока работает, поэтому предупреждение легко отложить.
Но wraparound связан не с размером таблицы и не только с dead tuples.
PostgreSQL использует ограниченное циклическое пространство transaction ID. Старые версии строк нужно вовремя замораживать, чтобы после оборота XID они не выглядели как версии «из будущего».
Важно различать:
очистка dead tuples → повторное использование места
freeze → защита от XID wraparound
Даже почти статичная таблица может нуждаться в freeze.
С чего начать диагностику:
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;
datfrozenxid — не средний возраст строк. Его удерживает самое старое отношение внутри базы.
После этого ищут таблицу или TOAST с максимальным возрастом relfrozenxid.
Одного факта «VACUUM запускался» недостаточно. Нужно проверить:
— снизился ли age(relfrozenxid);
— завершился ли vacuum;
— не был ли он отменён;
— не находится ли старый XID в TOAST;
— не мешают ли долгие транзакции или prepared transactions;
— как быстро система расходует XID;
— насколько близко значение к настройкам конкретной версии и системы.
Anti-wraparound autovacuum запускается даже при отключённом обычном autovacuum. Отменять его как «неудобную фоновую уборку» опасно.
Если предупреждения игнорировать, PostgreSQL перестанет назначать новые XID. Записывающие операции начнут завершаться ошибками, хотя read-only-нагрузка ещё может работать.
Типичная ошибка:
anti-wraparound autovacuum грузит диск
→ отменим
→ запустим обычный VACUUM потом
Так можно сократить оставшийся запас XID.
Не начинайте с VACUUM FULL, массового VACUUM FREEZE или изменения freeze-параметров без анализа версии, таблиц и окна обслуживания.
Вывод: риск wraparound нужно искать до аварийного сообщения — по возрасту datfrozenxid, relfrozenxid, TOAST-отношений и динамике расходования XID.
Сохраните набор признаков, по которым риск XID wraparound нужно искать до аварийного сообщения.
🔹🔹🔹🔹