[dfox]

> This process of retrieving the expected database state from the WAL is called logical decoding and Postgres stores files related to this process in here.

While logical decoding is about WAL, it is not related to the recovery process. Logical decoding is a mechanism to convert the WAL entries back into the high-level operations that caused the WAL entries, for example for replication or audit.

[hinkley]

But in a power loss the WAL is also read to restore and transactions that were in flight, right?

[ggm]

"in case of disk loss, we wrote the things we were going to write to disk, to the WAL. which is also on disk"

I never entirely got it. Either your WAL is on more reliable media, or duplicated. If its just "easier" to write the WAL and faster to read off properly indexed state, ok, thats a local optimisation.

If your WAL is on the same filesystem behind a vendor specific RAID controller, you're still stuffed, if that RAID card dies.

[Doxin]

the WAL is not for when your disk dies. It's for when the server crashes. First writing what you're going to do to the WAL before doing it makes it possible to recover from a crash at any point. If it crashes during writing to the WAL? Ignore the half-written WAL records and keep trucking. If it crashes during writing to the data file? Use the WAL to rerun the writes that didn't complete.

It doesn't guarantee you don't lose data written during the crash, but it does guarantee you can get the database back into a usable state.

[drewsberry]

Very good point, I've rephrased this.

[dfox]

You still refer to logical decoding as part of recovery in the last section. The main point is that WAL by itself is designed only for data recovery and only contains information about what is going to be written where in terms of essentially raw disk accesses (notably, the writes do not have to be page aligned).

Logical decoding (which needs wal_level=logical which extends the WAL format with additional metadata) is about parsing the WAL for other purposes than performing the recovery (or physical replication, which is essentially the same thing as recovery, but performed on another instance of the same cluster). The name "logical decoding" is certainly intended to emphasize that there are other uses for that than logical replication, but these are not that different from logical replication on this level (get a stream of changed tuples in tables).