Also, partially applying a WAL has obvious issues even though the author of this post would somehow prefer that. If we update 3 rows in a database and the WAL entry for one of the rows is corrupted, do they expect to ignore the corrupted entry and apply the rest? What happens to data consistency in this particular case?

▲

lxgr 2 days ago | parent [-]

Even worse: SQLite, by default, does not immediately truncate WAL files, but rather overwrites the existing WAL from the beginning after successfully applying a checksum.

Doing what the author suggests would actually introduce data corruption errors when "restoring a WAL with a broken checksum".

▲

avinassh 2 days ago | parent [-]

However, SQLite, by default, always truncates the WAL files on last connection close

> When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and its associated shared-memory file, to clean up the disk.

https://www.sqlite.org/wal.html

	▲	lxgr 2 days ago \| parent [-]
		Yes, but you can't rely on an orderly database close when it comes to correctness. Non-clean shutdowns are much more common than actual low-level data corruption in many SQLite applications.