# Postgresql – Difficulty understanding Postgres synchronous_commit = off and data loss

postgresql

I am confused what "data loss" means the context of synchronous_commit = off.

It sounds like synchronous_commit = off is pretty safe to increase write perf, and may result in "data loss", but not "data corruption" which sounds a lot worse.

So as I understand, if things crash, I might have lost some data a second before the crash. But the database is still consistent and not "corrupted", so I can simply re-run what didn't go through once it's back up, correct? My database does not end up in a state where it "kinda happened" and all the data is messed up?

I think it may also help me understand to give me examples where synchronous_commit = off is NOT ok to use.

In the documentation (https://www.postgresql.org/docs/11/wal-async-commit.html) it says:

Thus asynchronous commit should not be used if the client will take external actions relying on the assumption that the transaction will be remembered. As an example, a bank would certainly not use asynchronous commit for a transaction recording an ATM's dispensing of cash. But in many scenarios, such as event logging, there is no need for a strong guarantee of this kind.

I am confused because the ATM dispensing cash is too obvious of an example, and the event logging example does not go into enough depth for me to understand the difference.

Say we wanted to sequentially save 3 items in our database table called numbers: [1, 2, 3]
And we have a client that queries the table numbers for what was last saved, and will resume from where it left off.

numbers
---
id
---
1


So if we ran our client, it will find 1 and start at 2. Now if we write 2, with asynchronous commit we get a premature success signal back, but then our database suddenly crashes before it can actually persist. Now if we were to restart our client, would it resume from 2 again (correct) or skip it and start with 3 (incorrect)?