Фиксация транзакции

Покупатель отправил заказ, соединение оборвалось, а приложение не получило подтверждение. Заказ мог уже сохраниться. Нужно установить исход именно этой операции и следовать правилам разрешённого повтора. Слепое повторное создание заказа или оплаты способно превратить неизвестный результат в два выполненных действия.

1. 01

   Фиксация завершает транзакцию принятием её результата. В PostgreSQL 18 политика WAL и репликации задаёт этапы, которых база ждёт перед подтверждением: общий смысл COMMIT не заменяет проверку этих настроек.

   Граница применимости: Модель транзакции и подтверждение PostgreSQL 18; момент видимости для уже существующих снимков и разных реплик рассматривается отдельно.

2. 02

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

   Граница применимости: Редакторский вывод для явно заданного окна потери ответа после COMMIT: руководство PostgreSQL 18 задаёт границы фиксации и отката, а RFC 9110 §9.2.2 — основания безопасного повтора HTTP-запроса. Потеря ответа — предпосылка сценария, а не дословное утверждение этих страниц о SQL-соединении; RFC не задаёт готовый протокол повтора транзакции.

3. 03

   Успешный INSERT внутри незавершённого блока PostgreSQL 18 ещё не фиксирует заказ. Следующий полный ROLLBACK отменит эту запись; успешный результат промежуточной команды нельзя выдавать за успешную фиксацию всей транзакции.

   Граница применимости: PostgreSQL 18, явный блок BEGIN с транзакционной таблицей; нет промежуточной фиксации и независимого соединения.

4. 04

   Код HTTP-ответа описывает обработку запроса по контракту сервиса, а не универсальную границу транзакции базы. Чтобы считать ответ подтверждением заказа, сервис должен определить, какой результат и какая фиксация за ним стоят; отсутствие ответа само по себе не описывает состояние SQL-транзакции.

   Граница применимости: Сопоставление семантики HTTP и локального блока SQL; не привязка любого статуса 200 к одному виду операции.

5. 05

   По рекомендации RFC 9110 клиенту не следует автоматически повторять запрос с неидемпотентным методом без известной идемпотентной семантики операции или способа установить, что исходный запрос не был применён. Для повторного создания заказа одного факта обрыва соединения недостаточно.

   Граница применимости: HTTP, RFC 9110 §9.2.2; последнее предложение — применение правила к созданию заказа без известного безопасного контракта повторов.

6. 06

   Отсутствие заказа на асинхронной реплике после неясного завершения не доказывает откат на основном узле: реплика может ещё не получить или не применить запись. Проверка исхода должна учитывать источник чтения и его подтверждённую полноту относительно исходной операции.

   Граница применимости: Редакторское сопоставление потерянного ответа и отставания PostgreSQL 18; не обещание, что любая новая копия после переключения содержит исходную фиксацию.

1. Установите точную границу: когда закончилась запись заказа, когда база зафиксировала её и когда сервис отправил подтверждение.
2. Свяжите запрос, заказ и проверку результата одним предусмотренным приложением идентификатором деловой операции.
3. На стенде оборвите ответ после принятия фиксации и проверьте, что приложение не объявляет откат только по тайм-ауту.
4. Для проверки результата укажите источник чтения и доказательство, что он содержит нужную историю; отставшая реплика не даёт вывода об отсутствии заказа.
5. Повторяйте запрос только по определённому контракту; отдельно проверьте, как сервис исключает повтор внешнего платежа.
6. Проверьте ветку, в которой после успешного INSERT другая команда завершается ошибкой и вся транзакция откатывается.
7. В интерфейсе различайте подтверждённый успех, подтверждённую отмену и пока неизвестный результат; назначьте способ разрешения последнего.

• Первичная публикация

  The Transaction Model — Turing Award Lecture

  Microsoft Research / ACM · Jim Gray, FCRC 1999 lecture slides

  Первичный обзор transaction model, ACID, concurrency anomalies, logs и two-phase commit.

  Открыть первоисточник ↗
• Официальная документация

  PostgreSQL 18 Documentation: Write-Ahead Logging

  PostgreSQL Global Development Group · PostgreSQL 18, Chapter 28.3

  Определяет write-ahead rule, REDO crash recovery и роль checkpoint.

  Открыть первоисточник ↗
• Официальная документация

  PostgreSQL 18 Documentation: WAL Configuration

  PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года

  Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить fsync, synchronous_commit=off/on/remote_write/remote_apply и условия ожидания синхронных реплик.

  Открыть первоисточник ↗
• Официальная документация

  PostgreSQL 18 Documentation: Transactions

  PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года

  Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить границы BEGIN/COMMIT/ROLLBACK, отдельные транзакции без BEGIN, точки сохранения и оговорку о поведении клиентских библиотек.

  Открыть первоисточник ↗
• Первичная спецификация

  HTTP Semantics

  Internet Engineering Task Force · RFC 9110, June 2022

  Определяет stateless HTTP, origin server, intermediaries, target URI и security significance полей authority и Host.

  Открыть первоисточник ↗
• Официальная документация

  PostgreSQL 18 Documentation: Log-Shipping Standby Servers

  PostgreSQL Global Development Group · PostgreSQL 18, Chapter 26.2

  Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.

  Открыть первоисточник ↗