> MySQL and PG are not truly consistent per default, they don't fsync every writes.

Postgres most certainly does fsync by default.

It's tru, you can disable it, but there is a big warning about "may corrupt your database" in the config file.

> It writes out and syncs the accumulated WAL records at each transaction commit, unless the committed transaction touched only UNLOGGED or TEMP tables, or synchronous_commit is turned off.

So wal is synced before commit returns, and if you power cycle immediately after, the wal is played back and your transaction is not lost? So it's fine?

It does not need to sync all writes, only the records needed to play back the transaction after restart. This is what all real databases do.

“PG writes out and syncs the accumulated WAL (= Transaction log) records at each transaction commit [snip] It also syncs at the end of each WAL file (16MB by default). The wal_writer process also wakes up occasionally and writes out and syncs the WAL.“

So PG keeps data consistent by default - unlike MongoDB.

> MySQL and PG are not truly consistent per default, they don't fsync every writes. MongoDB explains that pretty well [links]

Where in those MongoDB doc links is there anything about MySQL or PG?

I don't know if this is true or not, but it's besides the point; MongoDB omitted various failings from the Jepsen report to make their product look better than it actually is. This is not only unethical, but may also be illegal in various jurisdictions under false advertising laws.

Whatever failings MySQL or PostgreSQL may or may not have are not important at all here.

The default in MySQL and in postgresql is to fsync before commit and afaik that has always been the default.

That bug was unfortunate, but you can't say that "it doesn't fsync" because, pedantically, it does, it just ignores the return value.

And, obviously that's a bug, it's designed to do so.

Also, if you write with O_DIRECT, a fsync is not needed, as it's how you tell the OS to block until written.