CLOG, XID wraparound и MultiXact

Sentry 2017: autovacuum отстал, 32-битный XID-счётчик приблизился к потолку, Postgres отказался принимать новые соединения и завершился с сообщением «database is not accepting commands to avoid wraparound data loss». Ручная заморозка под огнём. Разберём механику до байта.

HeapTupleSatisfiesMVCC и hint-биты

Решение видимости на каждом tuple реализовано в HeapTupleSatisfiesMVCC(HeapTuple, Snapshot, Buffer) в heapam_visibility.c. Функция проходит по дереву решений через биты t_infomask:

Когда биты выставлены — прямое решение без CLOG. Когда нет — функция лезет в CLOG, получает ответ и записывает hint-бит обратно на страницу.

Почему это важно операционно: SELECT сразу после долгого INSERT может быть медленнее, чем тот же SELECT секундой позже. Первый скан трогает CLOG-запись каждого tuple и пишет hint-биты; второй скан читает биты напрямую.

CLOG (commit log)

Каждый коммиченный или откатанный XID записывается в pg_xact/ (раньше pg_clog/): 2 бита на transaction id, упакованные в страницы по 8 КБ. Одна страница покрывает 16 384 транзакции.

CLOG активно кешируется (clog_buffers). Hint-биты на tuple избегают CLOG-lookup; но на свежезаписанном tuple первый читатель обязан спросить CLOG.

После коммита транзакции биты в CLOG надёжно на диске благодаря WAL. Именно поэтому fsync = on и synchronous_commit = on непереговариваемы: коммит, подтверждённый до того как WAL ушёл на диск, может оставить CLOG несогласованным на восстановлении.

XID wraparound и заморозка

Transaction id в Postgres 32-битные. На ~2B транзакций счётчик переполнится, и старые xmin/xmax выглядели бы новее, чем они есть — катастрофа корректности.

Механизм предотвращения: Как только tuple “достаточно старый” (старше autovacuum_freeze_max_age, дефолт 200M транзакций), VACUUM переписывает его t_xmin на FrozenTransactionId — специальное значение, всегда видимое любому snapshot.

Пороги эксплуатации:

SELECT datname, age(datfrozenxid) FROM pg_database;

VACUUM wraparound-prevention — задача autovacuum высшего приоритета: запускается даже когда autovacuum = off. На базе, приближающейся к 2B без достаточной заморозки, Postgres отказывает в соединениях с сообщением database is not accepting commands to avoid wraparound data loss.

Sentry 2017: autovacuum отстал на кластере с интенсивной записью — закончилось ручной заморозкой VACUUM FREEZE для восстановления.

MultiXact и shared row locks

Когда несколько транзакций хотят держать неэксклюзивную блокировку на одной строке (SELECT ... FOR SHARE, FOR KEY SHARE), Postgres не может разместить несколько XID в единственное поле t_xmax.

Вместо этого выделяется MultiXactId — 32-битный id, указывающий в pg_multixact/, где перечислены участники и их режимы блокировок.

MultiXact имеет собственный wraparound (тоже 2B), отслеживается отдельно и замораживается на отдельном расписании.

Нагрузка с интенсивным SELECT ... FOR KEY SHARE (неявная блокировка от проверок foreign key) может попасть в MultiXact wraparound задолго до XID wraparound.

SELECT datname, age(datfrozenxid), age(datminmxid) FROM pg_database;

Симптом MultiXact проблемы: autovacuum: found xxx nonremovable row versions ... dead row versions cannot be removed yet с высоким “oldest MultiXact” age.

Числа