Заморозка и переполнение счётчика (wraparound)

Каждой транзакции, которая меняет данные, PostgreSQL выдаёт xid - следующее число счётчика. Видимость версии решается сравнением её xmin/xmax с номерами транзакций в снимке: меньше - в прошлом, больше - в будущем.

Проблема в том, что 32-битный счётчик вмещает чуть больше четырёх миллиардов значений (2³²). На активной базе это не «никогда» - это месяцы или даже недели. Когда счётчик доходит до предела, он обнуляется и начинает заново.

Чтобы сравнения продолжали работать, PostgreSQL считает их не на прямой, а на круге. Для любого xid половина значений (примерно два миллиарда) считается «прошлым», вторая половина - «будущим».

Вот где ловушка: если версия строки осталась с xmin, который старше текущего более чем на два миллиарда, круг «перевернёт» её - она начнёт выглядеть как версия из будущего, ещё не наступившая. А значит, перестанет быть видимой. Данные на месте, но СУБД считает их несуществующими.

Решение - не дать ни одной версии состариться больше чем на два миллиарда транзакций. Для этого её xmin нужно «заморозить»: пометить как «эта версия старше всего на свете, видна всем безусловно, в сравнениях по кругу не участвует».

Исторически заморозка переписывала xmin в специальное значение FrozenTransactionId (число 2). Современный PostgreSQL не трогает само xmin, а выставляет в заголовке кортежа бит-подсказку HEAP_XMIN_FROZEN: версия считается замороженной, а исходный xid остаётся виден для отладки. Результат тот же - замороженная версия выпадает из круга и больше никогда не «перевернётся».

Замораживает версии VACUUM. Обычный проход замораживает те, что уже достаточно стары (старше vacuum_freeze_min_age, по умолчанию 50 миллионов). А когда таблица в целом стареет опасно - запускается агрессивный проход, который проходит даже те страницы, что карта видимости считает «всё видно всем», и замораживает всё подряд.

Как PostgreSQL понимает, что таблица стареет? У каждой таблицы есть relfrozenxid - граница, гарантирующая: все версии старше неё уже заморожены. Хранится в pg_class.

Полезнее смотреть не на само число, а на его возраст - на сколько транзакций оно отстало от текущего счётчика:

SELECT relname, age(relfrozenxid) AS xid_age

FROM pg_class

WHERE relkind = 'r'

ORDER BY age(relfrozenxid) DESC

LIMIT 10;

age(relfrozenxid) растёт с каждой новой транзакцией в базе и сбрасывается вниз, когда VACUUM проходит таблицу и продвигает relfrozenxid вперёд. Если возраст какой-то таблицы упорно растёт и приближается к 200 миллионам - её autovacuum по какой-то причине не обрабатывает, и пора разбираться.

На уровне всей базы то же самое показывает datfrozenxid в pg_database - это минимум по всем таблицам базы. Именно он определяет, насколько база близка к опасной черте. Подробности счётчиков - в freeze.

PostgreSQL не ждёт катастрофы пассивно. По мере роста возраста включаются всё более жёсткие меры - лестница из четырёх ступеней:

Разберём ступени:

• 200 млн (autovacuum_freeze_max_age) - запускается анти-wraparound autovacuum. Он стартует даже на таблице, которую autovacuum обычно не трогает, и даже если autovacuum выключен целиком. Это первая и обычно достаточная линия обороны;
• 1.6 млрд (vacuum_failsafe_age) - failsafe. VACUUM понимает, что времени мало, и переходит в режим выживания: пропускает очистку индексов и задержки, всё ради скорейшей заморозки;
• меньше 40 млн до края (примерно возраст 2.1 млрд) - сервер начинает писать в лог настойчивые WARNING с обратным отсчётом;
• меньше 3 млн до края - сервер отказывается выдавать новые xid. База перестаёт принимать запросы, меняющие данные. Выход один: остановить сервер и запустить VACUUM в однопользовательском режиме.

Если все предохранители проигнорированы и база встала, спасение выглядит так:

# сервер остановлен; запускаем его в single-user режиме

postgres --single -D /var/lib/postgresql/data <имя_базы>

backend> VACUUM;

В этом режиме к базе подключён ровно один процесс, никаких клиентов. VACUUM проходит и замораживает старые версии, datfrozenxid продвигается, и после рестарта база снова принимает запросы.

Это аварийный сценарий, и попадать в него не нужно. Вся лестница выше существует именно для того, чтобы анти-wraparound autovacuum разобрался с заморозкой задолго до дна. До single-user доходят обычно те, кто намеренно отключил autovacuum «ради производительности» - классическая дорогая ошибка. Подробнее про сам механизм круга - в wraparound.

У wraparound есть младший брат, про которого часто забывают. Когда одну строку одновременно блокируют несколько транзакций (например, SELECT ... FOR SHARE или проверки внешних ключей), PostgreSQL не может записать в xmax один xid - блокировщиков несколько. Вместо этого он заводит multixact: отдельный идентификатор, за которым стоит список транзакций-участников.

Multixact-идентификаторы - тоже 32-битный счётчик со своим кругом и своим переполнением. У таблицы для него есть relminmxid (аналог relfrozenxid), а пороги называются autovacuum_multixact_freeze_max_age (по умолчанию 400 миллионов). VACUUM замораживает и multixact тоже.

Коварство в том, что мониторинг часто следит только за обычным age(relfrozenxid) и упускает age(relminmxid). На нагрузке с большим количеством блокировок строк или внешних ключей второй счётчик может побежать к краю быстрее первого. Смотреть надо за обоими. Разбор - в multixact.

Копнуть глубже: заморозка в PostgreSQL 17 стала дешевле. VACUUM хранит список «мёртвых» указателей в памяти, и в прежних версиях этот буфер был ограничен одним гигабайтом, из-за чего большим таблицам приходилось делать несколько проходов по индексам. В 17-й версии структуру заменили на компактное дерево, которое вмещает на порядки больше указателей в той же памяти. На больших таблицах это заметно ускоряет и заморозку, и обычную уборку.