clog, подсказки фиксации и вложенные транзакции

Поля xmin и xmax - это просто номера транзакций (см. xmin-xmax). По ним нельзя сказать, чем транзакция кончилась: коммитом или откатом. А правило видимости спрашивает это постоянно, на каждую проверяемую версию: «транзакция, создавшая её, точно закоммитилась?»

Хранить ответ прямо в строке нельзя: в момент создания версии её транзакция ещё не знает своей судьбы. Значит, статус живёт отдельно, и его надо где-то быстро находить. Это «где-то» называется clog.

Статус каждой транзакции хранится в clog - каталоге pg_xact/ внутри PGDATA. На транзакцию приходится всего два бита:

Два бита на транзакцию - это очень компактно. Статусы миллионов транзакций умещаются в мегабайты, а горячая часть кэшируется в памяти. Когда правило видимости спрашивает «xmin закоммитился?», ответ ищется в clog по номеру транзакции.

Лезть в clog на каждую строку при каждом чтении дорого. Поэтому ответ кэшируется прямо в строке - подсказками фиксации (hint bits) в поле t_infomask (см. tuple-header).

Флаг «xmin точно зафиксирован» ставит первый, кто прочитал строку после завершения её транзакции. Дальше clog для этой строки не тревожат: ответ уже в ней. Подробнее - в clog-hint-bits.

Вот неожиданное следствие. Подсказку ставит чтение, а установка подсказки меняет байты страницы. Поймаем это руками. Вставим строку в отдельной транзакции, а потом посмотрим на её infomask до и после обычного чтения:

CREATE TABLE hb (id int);

INSERT INTO hb VALUES (1);

-- сразу после вставки: бит HEAP_XMIN_COMMITTED (256) ещё не стоит

SELECT (t_infomask & 256) FROM heap_page_items(get_raw_page('hb', 0));

-- 0

SELECT * FROM hb;     -- обычное чтение проверяет видимость и ставит подсказку

-- теперь бит стоит

SELECT (t_infomask & 256) FROM heap_page_items(get_raw_page('hb', 0));

-- 256

Обычный SELECT * FROM hb поменял страницу: бит HEAP_XMIN_COMMITTED перешёл из 0 в 256. А раз страница изменилась - она помечена грязной и будет записана на диск. Получается, безобидное чтение вызвало запись.

Эффект «SELECT, который пишет» объясняет загадочную просадку производительности. Сразу после массовой загрузки данных первый запрос, который их читает, расставляет подсказки фиксации по всем свежим строкам - и вызывает шквал записи. Поэтому «холодное» первое чтение только что загруженной таблицы бывает заметно дороже последующих.

Это не утечка и не баг, а отложенная работа: фиксацию статуса размазывают по первым чтениям, вместо того чтобы делать её всю при коммите. Зная это, не пугаешься, увидев запись от чисто читающего запроса в мониторинге сразу после загрузки.

Закроем тему транзакций вложенностью. Точка сохранения (savepoint) открывает подтранзакцию внутри основной и позволяет откатить часть работы, не теряя всю транзакцию:

BEGIN;

INSERT INTO hb VALUES (2);

SAVEPOINT s1;

INSERT INTO hb VALUES (3);

ROLLBACK TO SAVEPOINT s1;   -- отменили только вставку 3

COMMIT;                     -- 2 осталась, 3 - нет

Каждая пишущая подтранзакция получает свой xid, а связь «подтранзакция - родитель» хранит каталог pg_subtrans. Версии, созданные в откаченной подтранзакции, становятся невидимы - правило видимости отсекает их так же, как версии откатившейся обычной транзакции. Подробно - в subtransactions.

Подтранзакции возникают и неявно. Блок BEGIN ... EXCEPTION ... END в PL/pgSQL оборачивается в подтранзакцию: если внутри ошибка, откатывается она, а не вся транзакция. Удобно - но у этого есть цена.

У каждого backend'а небольшой кэш на 64 активные подтранзакции. Если открыть больше (тысячи savepoints или блоков EXCEPTION в горячем цикле), кэш переполняется, и проверка видимости начинает ходить в pg_subtrans за каждым номером. Это тормозит всю систему, а не только виновника. Поэтому массовые подтранзакции в цикле - антипаттерн, даже когда логически они корректны. На этом часть про MVCC завершается: дальше мы разберём, кто и как убирает мусор, который вся эта многоверсионность оставляет.