"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.
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.
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.