4 ms·
You might roll back committed transactions in case of a system crash. It might be acceptable for some applications, but I wouldn't certainly call it extremely r
by gpderetta 4y ago
You might roll back committed transactions in case of a system crash. It might be acceptable for some applications, but I wouldn't certainly call it extremely reasonable.
If you do not care about system crashes, why sync at all?
- wongarsu 4y agoI've written plenty systems that would be fine with a valid, consistent but maybe slightly older state (for example when the db describes both work to be done and work results, or the db otherwise implicitly records where to resume work). On the other hand there are obvious examples where this is unacceptable, say recording the transactions of a cash register.
- gpderetta 4y agoI have done as well! My concern is the assertion that this behavior is reasonable for the vast majority of applications.
- JohnBooty 4y agoIf you do not care about system crashes, why sync at all? Well, you have to sync sometime if you care about persist your data at all, right? And there are scads of use cases where you want to: - persist data - enforce some sort of schema (even though SQLite is lax here) - query/join it in SQL-y ways - are willing to trade ACID-compliant journaled durability in exchange for performance Cache stores are maybe the most obvious use case. This is roughly how Redis is configured out of the box after all (sans the SQL) IIRC. Not ideal if your cache is trashed but also, not a huge deal. There are also a lot of logging/timeseries type applications where it's just not a big deal if you lose, say, a few minutes of data per year.
- gpderetta 4y agoIf you only need best effort and preserve data only in the case of an application crash, you do not need sync(2) at all, just call write.