LisPi on Nostr: nprofile1q…utslx akko Normal Mikoto :kagami_shrug: :gekota: Even if it does fsync, ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0cq07ulfyc7y2l8rczk9s36g8j65tq3m6xk9us8hr3ua4ktfmaqqeutslx (nprofile…tslx) akko (nprofile…wssg) Normal Mikoto :kagami_shrug: :gekota: (nprofile…nc0q) Even if it does fsync, if the write gets interrupted, the on-disk state of an overwrite will be inconsistent.
Journaling the write means that if the write gets interrupted before it is a valid journal entry, then it's discarded entirely & state is unchanged, and if it gets interrupted before it is written out to disk after it has been journaled, then it can be recovered without issue.
Databases in theory should be designed to cope, but some of them might rollback recent transactions if write consistency isn't present.
https://www.sqlite.org/atomiccommit.html The assumptions of what happens after a flush matter here.
> If after power is restored the file is only partially deleted, if some of its data has been altered or erased, or the file has been truncated but not completely removed, then database corruption will likely result.
> [...]
> The default synchronous setting is full so the above is what usually happens. However, if the synchronous setting is lowered to "normal", SQLite only flushes the rollback journal once, after the page count has been written. This carries a risk of corruption because it might happen that the modified (non-zero) page count reaches the disk surface before all of the data does.
In other words, one's settings matter and I'm advocating for the strictest consistency & integrity position (don't follow silly online advice for "performance" without understanding the tradeoff).
PostgreSQL meanwhile has this to say: https://www.postgresql.org/docs/current/wal-reliability.html
Journaling the write means that if the write gets interrupted before it is a valid journal entry, then it's discarded entirely & state is unchanged, and if it gets interrupted before it is written out to disk after it has been journaled, then it can be recovered without issue.
Databases in theory should be designed to cope, but some of them might rollback recent transactions if write consistency isn't present.
https://www.sqlite.org/atomiccommit.html The assumptions of what happens after a flush matter here.
> If after power is restored the file is only partially deleted, if some of its data has been altered or erased, or the file has been truncated but not completely removed, then database corruption will likely result.
> [...]
> The default synchronous setting is full so the above is what usually happens. However, if the synchronous setting is lowered to "normal", SQLite only flushes the rollback journal once, after the page count has been written. This carries a risk of corruption because it might happen that the modified (non-zero) page count reaches the disk surface before all of the data does.
In other words, one's settings matter and I'm advocating for the strictest consistency & integrity position (don't follow silly online advice for "performance" without understanding the tradeoff).
PostgreSQL meanwhile has this to say: https://www.postgresql.org/docs/current/wal-reliability.html