My feeling is that any portion that no longer checksums correctly is practically forfeited, which makes any form of recovery an arbitrary result - a half-baked transaction. I don't see how that's a more desirable outcome than rolling back to the last known-good commit, which is never arbitrary.

▲

avinassh 2 days ago | parent [-]

I posted in another comment: There is a smoll demo in the post. In it, I corrupt an old frame that is not needed by the database at all. Now, one approach would be to continue the recovery and then present both states: one where the WAL is dropped, and another showing whatever we have recovered. If I had such an option, I would almost always pick the latter.

▲

nemothekid 2 days ago | parent | next [-]

>one where the WAL is dropped, and another showing whatever we have recovered. If I had such an option, I would almost always pick the latter

I can't imagine picking the latter unless you were treating sqlite like a filesystem of completely unrelated blobs.

If I run three transactions where:

1. John gives $100 to Sue.

2. Sue gives $100 to Mark.

3. Mark $100 money to Paul.

If sqlite, just erases transaction (2), then Mark materializes $100 from nowhere. The rest of your database is potentially completely corrupted. At that point your database is no longer consistent - I can't see how you would "almost always" prefer this.

If (2) is corrupt, then the restore stops at (1), and you are guaranteed consistency.

	▲	avinassh 2 days ago \| parent [-]
		Yes, this is a good example of showing an we cannot partly apply the WAL always. Again, let me repeat it, we cannot partly apply the WAL all the time expect it to work but there are some valid cases where we can do that to recover. Your example is not the one.

▲

2 days ago | parent | prev [-]

[deleted]