Заголовок tuple и механика снимков

Postgres читает три числа из заголовка каждой строки, сравнивает их с тремя числами в snapshot транзакции и принимает решение о видимости — без единой read-блокировки. Разберём механику побайтово.

Заголовок tuple

Когда Postgres сохраняет tuple на heap-странице, перед пользовательскими колонками идёт 23-байтный заголовок:

Именно эти поля решают вопрос видимости на каждой строке, которую Postgres смотрит.

Как snapshot решает, что читать

Когда транзакция начинается — при первом запросе под READ COMMITTED, или на BEGIN под REPEATABLE READ — Postgres строит snapshot. Это небольшая структура, фиксирующая три числа:

• xmin — id самой старой ещё работающей транзакции
• xmax — id на единицу больше последнего закоммиченного на момент snapshot
• xip — список незавершённых транзакций между xmin и xmax

Правило видимости (применяется построчно):

Tuple виден, если:

• его t_xmin закоммичен и не в списке xip, И
• его t_xmax равен нулю, ИЛИ откатан, ИЛИ в списке xip

Никаких read-блокировок не задействовано — это и есть весь механизм.

INSERT, UPDATE, DELETE — что реально происходит на диске

INSERT — кладёт свежий tuple с t_xmin = id текущей транзакции, t_xmax = 0.

UPDATE — две операции:

1. Помечает старый tuple: t_xmax = текущая транзакция
2. Вставляет новый tuple: t_xmin = та же транзакция; t_ctid старого указывает на адрес нового

DELETE — помечает существующий tuple: t_xmax = текущая транзакция. Ничего нового не пишет.

Ни одна из операций не удаляет ничего физически. Все логически обратимы до коммита, а после коммита по-прежнему физически на месте, пока VACUUM не решит, что они больше никому не нужны.

Пример: параллельный UPDATE и SELECT