Фиксация принимает результат транзакции. Долговечность описывает, какой отказ принятый результат переживёт. У PostgreSQL 18 ослабленный synchronous_commit меняет момент подтверждения, поэтому само слово COMMIT без настроек не задаёт достаточную гарантию хранения.
Практический смысл
Почему это важно
Заказ, подтверждённый до аварии, может быть важнее последних миллисекунд ответа. Согласуйте, когда база вправе сообщить об успехе и какая копия должна пережить требуемый отказ. При выборе тракта хранения проверяют выполнение команд устойчивой записи; при выборе репликации — отдельную пригодную копию и этап, которого ждёт фиксация.
Доказательная часть
Что подтверждено
Долговечность связывает принятое подтверждение фиксации с сохранением результата при предусмотренном отказе. Гарантия требует точного условия: сохранённый локально журнал помогает при восстановлении того же хранилища, а полная утрата единственного носителя требует другой пригодной копии.
Граница применимости: Модель долговечности и механизмы PostgreSQL 18; логическая сохранность, независимая реплика и защита от утраты носителя не отождествляются.
Надёжная фиксация текущего состояния может столь же надёжно сохранить ошибочное удаление. Возврат к состоянию до ошибки требует сохранённой истории и работоспособного пути восстановления; одна долговечность этой истории не создаёт.
Граница применимости: Долговечность в сравнении с восстановлением после логической ошибки; PostgreSQL 18 PITR — конкретный пример механизма истории.
В PostgreSQL 18 долговечная фиксация не требует сразу записывать все изменённые страницы таблиц. Достаточно устойчиво сохранить нужные записи WAL: после сбоя журнал позволяет повторить ещё не перенесённые в файлы данных изменения.
Граница применимости: PostgreSQL 18, правило предварительной записи журнала и восстановление при сохранном необходимом хранилище; не режим synchronous_commit=off.
В PostgreSQL 18 synchronous_commit=off позволяет сообщить об успехе до устойчивой записи WAL. При сбое последние уже подтверждённые транзакции могут быть потеряны; это ослабление долговечности не означает допустимость частично выполненных транзакций в восстановленной базе.
Граница применимости: PostgreSQL 18, асинхронная фиксация при корректно работающем fsync; её последствия отличаются от отключения fsync.
В PostgreSQL 18 отключение fsync убирает требуемую защиту порядка и устойчивости записи при аварии и может привести к повреждению базы. Это другой риск, чем окно потери последних транзакций при synchronous_commit=off; режимы нельзя считать взаимозаменяемой настройкой ускорения.
Граница применимости: PostgreSQL 18, параметры fsync и synchronous_commit; предполагается авария, затрагивающая ещё неустойчивые записи.
При настроенных синхронных репликах PostgreSQL 18 remote_write ждёт записи в файловую систему реплики, on — устойчивой записи её WAL, remote_apply — применения, после которого изменения доступны новым подходящим снимкам чтения. Уже открытый старый снимок Repeatable Read от этого не обновляется. Переживаемые отказы и момент видимости различаются.
Граница применимости: PostgreSQL 18, synchronous_commit и требуемые синхронные реплики. remote_write не обещает пережить отказ ОС реплики; без настроенных синхронных реплик удалённое ожидание не возникает.
Гарантия устойчивой записи зависит от того, что весь тракт хранения действительно выполняет запросы сброса. Если оборудование сообщает об устойчивом сохранении, а данные остаются только в теряемом при питании кэше, успешное ожидание со стороны базы не доказывает сохранность после потери питания.
Граница применимости: Требования PostgreSQL 18 к надёжности fsync и физической записи; конкретные контроллер, накопитель и режим кэша требуют собственных паспортных и испытательных данных.
Граница терминов
Не путать
Долговечность защищает принятое состояние в оговорённой модели отказов. Проверенное восстановление подтверждает достижение нужного состояния из доступных материалов. Для отмены ошибочного удаления требуется подходящая сохранённая история, даже если удаление было безупречно зафиксировано.
Перед спецификацией
Что проверить
- Согласуйте событие подтверждения заказа и отдельно перечислите покрываемые отказы процесса, ОС, питания, носителя и площадки.
- Снимите действующие значения fsync и synchronous_commit в том соединении, которое фиксирует заказ.
- Для синхронного режима проверьте, какие реплики обязательны и какого удалённого этапа ждёт фиксация.
- Проверьте по документации и испытаниям, как контроллер и накопители выполняют сброс и что происходит с кэшем при потере питания.
- На отдельном стенде воспроизведите предусмотренный аварийный отказ и сопоставьте подтверждённые операции с восстановленными.
- Не требуйте немедленной записи всех страниц как единственного доказательства: отдельно проверяйте сохранность и пригодность необходимого WAL.
- Выполните восстановление до тестового ошибочного удаления из независимых материалов и проверьте состояние заказа в приложении.
Открытые основания
Первоисточники
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: Log-Shipping Standby Servers
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 26.2
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.
Открыть первоисточникPostgreSQL 18 Documentation: Continuous Archiving and Point-in-Time Recovery
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 25.3
Связывает base backup, непрерывный WAL archive и проверяемый recovery target.
Открыть первоисточник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: Transaction Isolation
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.2
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Открыть первоисточникPostgreSQL 18 Documentation: Reliability
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить выполнение сброса всем трактом хранения, энергозависимые кэши накопителя и контроллера и границы гарантии при потере питания.
Открыть первоисточникPostgreSQL 18 Documentation: Transactions
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить границы BEGIN/COMMIT/ROLLBACK, отдельные транзакции без BEGIN, точки сохранения и оговорку о поведении клиентских библиотек.
Открыть первоисточник