What an acknowledged commit promises
A fully durable commit requires enough information to survive the promised failures before success is acknowledged. A subsequent process crash should not erase the committed effects.
Every changed data page need not be written to its final location at each commit. PostgreSQL can first persist the corresponding write-ahead log, write data pages later, and redo missing changes during recovery.
The storage path participates
Data can pass through operating-system, controller, and device caches before reaching persistent storage. A completed write call does not necessarily establish power-loss safety; synchronization and truthful device behavior matter.
Protected caches and volatile write-back caches tolerate different failures. Reliable storage supports the commit guarantee, while backups address wider losses such as destruction of the medium itself. Durability is always relative to a stated failure model.
References: [2]
Asynchronous acknowledgement changes the promise
PostgreSQL asynchronous commit can acknowledge success before its log reaches permanent storage, reducing waiting for short transactions. A crash in that window can lose recently acknowledged work.
The documentation distinguishes this risk from arbitrary corruption: recovery still follows the persisted log to a consistent state. It also differs from disabling synchronization protections altogether. Throughput comparisons must account for the different promises attached to success.
References: [3]