3 ms·
Only skimmed through, so might be wrong, but got the impression that the mystery is never really solved… If transactions are batched, then MySQL will sometimes
by bjornsing 2y ago
Only skimmed through, so might be wrong, but got the impression that the mystery is never really solved… If transactions are batched, then MySQL will sometimes have to return OK before the transaction is on disk, no? But it’s stated that the configuration is fully ACID. Seems like a contradiction.
- mnahkies 2y agoThe transaction is written to the write ahead log and fsync'd before the client is told OK. It may not have made it to the table storage on disk yet (but will be in memory), but if there's a crash the WAL can be replayed to recover safely - you'll see postgres do this if it crashes from OOM or gets restarted unexpectedly
- deleted 2y ago[deleted]
- hackit2 2y agoI might be wrong but most disk controller report the file as written when it isn't actually written to the drive.
- darkwater 2y agoBut then it's in their cache which is battery-backed and survives power losses. It's the same concept as the write ahead log is at a higher level.
- ncruces 2y agoNo. Two non-conflicting transactions (where neither transaction reads the other's changes) can both wait for the other to commit, so they can be left hanging, and the COMMIT/fsync can be batched. Depending on how you interpret ACID, even two conflicting transactions (B reads what A wrote) can be left hanging. Whoever submitted A can be left blocked at COMMIT, while B is processed assuming A had committed; then either both commit or both fail. This is ACID as long as you only consider data committed once the COMMIT actually succeeds, and don't produce observable effects (outside the system) before that's true.
- bjornsing 2y agoThe performance test program does one insert at a time, sequentially…