ACID на практике

Что на самом деле даёт каждая буква

Если ты когда-нибудь отлаживал наполовину применённый пакет или удивлялся, почему «обернул в транзакцию» — а порча данных всё равно случилась, ответ почти всегда в том, какую букву ты предполагал против той, что реально получил.

ACID — это четыре гарантии, и инженеры путают ту, которой не получают, с теми, что получают.

• Atomicity (атомарность) — каждый оператор между BEGIN и COMMIT ложится вместе, или никакой. Любая ошибка или ROLLBACK выбрасывает весь пакет. Полуготовое состояние никогда не видно и не сохраняется.
• Consistency (согласованность) — закоммиченная транзакция оставляет базу удовлетворяющей всем ограничениям (foreign key, CHECK, unique, NOT NULL). Если оператор нарушит ограничение, транзакция падает с ошибкой и нужен откат. Postgres обеспечивает правила; твои инварианты («баланс не уходит в минус») ты кодируешь как ограничения, иначе они не гарантированы.
• Isolation (изоляция) — конкурентные транзакции не видят незакоммиченной работы друг друга. Важно: у изоляции есть уровни: по умолчанию READ COMMITTED — это слабое обещание, а не полная сериализуемость. Именно эту букву люди считают сильнее, чем она есть.
• Durability (долговечность) — как только COMMIT вернулся, изменение переживёт крах или потерю питания. Postgres гарантирует это, сбрасывая write-ahead log (WAL) на диск до подтверждения коммита.

-- Атомарный перевод денег: обе строки двигаются, или ни одна.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;   -- только теперь перевод долговечен и виден другим

Если второй UPDATE упадёт (скажем, счёт 2 удалён), транзакция переходит в aborted-состояние; первый UPDATE отбрасывается при ROLLBACK. Деньги не утекают.

BEGIN, COMMIT, ROLLBACK и неявная транзакция

Каждый оператор уже внутри транзакции. Вне явного BEGIN Postgres оборачивает каждый одиночный оператор в собственную транзакцию, которая коммитится автоматически (autocommit). Поэтому один UPDATE accounts SET balance = balance * 1.05 сам по себе атомарен — все подходящие строки меняются или ни одна, даже без BEGIN.

BEGIN ты пишешь только когда нужно сделать несколько операторов одной атомарной единицей. После ошибки внутри транзакционного блока Postgres отвергает каждый следующий оператор с current transaction is aborted, пока ты не сделаешь ROLLBACK (или COMMIT, который Postgres превратит в откат). Никакого «проигнорировать ошибку и продолжить» — если только не используешь savepoint.

SAVEPOINT: частичный откат внутри одной транзакции

SAVEPOINT — именованная метка, к которой можно откатиться, не бросая всю транзакцию. Она позволяет одной транзакции пережить восстановимую ошибку в части своей работы.

BEGIN;
INSERT INTO jobs (id, status) VALUES (501, 'queued');

SAVEPOINT try_dedupe;
-- это может нарушить unique-индекс, если задача уже есть:
INSERT INTO jobs (id, status) VALUES (501, 'queued');
-- падает; вместо потери всей транзакции откатываем только до savepoint:
ROLLBACK TO SAVEPOINT try_dedupe;

-- первый INSERT всё ещё жив; продолжаем и коммитим его:
COMMIT;

Именно это большинство драйверов делают под капотом для «вложенных транзакций» — в Postgres нет настоящих вложенных транзакций, только savepoint’ы. Цена, однако, реальна: каждый savepoint потребляет subtransaction ID, и транзакция, открывающая десятки тысяч их, может вызвать пресловутый subtransaction (subxid) overflow — как только backend превышает 64 живых подтранзакции, остальным приходится обращаться к pg_subtrans на диске, и задержка чтения на нагруженном primary может скакнуть с микросекунд до миллисекунд. Savepoint — скальпель, а не тело цикла.

Чего транзакция НЕ даёт

Транзакция по умолчанию — не мьютекс и не сериализуема. На READ COMMITTED (умолчание Postgres) каждый оператор видит свежий снимок, взятый в начале оператора, так что две конкурентные последовательности read-modify-write могут гоняться. Атомарность и долговечность ты получаешь бесплатно; защиту от lost update, write skew или фантомных строк ты не получаешь, пока не поднимешь уровень изоляции или не возьмёшь явные блокировки строк. Знание этой границы — вся причина, по которой существует остаток раздела.