The power cuts mid-transaction. Half your changes made it to disk, half didn't. On restart, which half? The database doesn't find out by inspecting the damage. It already knew.
Before touching the actual data pages, Postgres writes a small note: here is what I am about to change. Only once that note is safely on disk does the real work proceed.
The ordering is the whole trick. Transaction, append the intent to the log, fsync so the log is durable — and durability lands right there, at step three. Then modify the pages in memory, which is fast, and flush them to the data files much later. One sequential append costs far less than scattered random writes, so the guarantee comes first and the expensive part gets deferred.
After a crash, Postgres comes back up, replays the log, and reconstructs every committed change that never reached the data files. Incomplete transactions stay invisible to everyone else.
Then the same log turns out to have three more jobs. Standbys stream it to stay in sync. Point-in-time recovery rewinds the database with it. And it is a detailed record of everything that happened, which is an audit trail by another name.
Durability is making a promise you can still keep after the lights go out.