Write-ahead specifies an ordering
Tables and indexes can have modified pages in memory and partially updated files on storage. Write-ahead logging requires the relevant recovery records to reach persistent storage before corresponding page changes pass the required durability boundary.
Recovery can then reconstruct the intended state even when only some data pages were written. Merely creating a log record in memory is insufficient: the information must remain available after the failures being covered.
References: [1]
Commit through the log, write pages later
PostgreSQL normally synchronizes the necessary WAL records before acknowledging commit instead of flushing every changed data page. Sequential logging and group commits can reduce the cost of many small transactions.
After a crash, redo applies logged changes to pages requiring recovery. Each implementation defines record interpretation, recovery boundaries, and treatment of incomplete work. An informal activity log does not automatically provide these guarantees.
Recovery scope includes backups
A suitable physical backup plus subsequent archived WAL can support recovery to a point within the retained log coverage. Recovery depends on matching state and records, not an arbitrary fragment of recent log.
If both database and logs are lost, local recovery records cannot recreate them. Storage reliability, backup retention, and commit settings define the protection actually available; asynchronous acknowledgement additionally weakens survival of recent commits.