1173627 - Checkpoint the WAL after creating or updating tables.

Status: RESOLVED FIXED

(Firefox for iOS :: Data Storage, defect)

Comment 1

[Richard Newman [:rnewman]]

Attachment: Pull req.

Comment 2

[Richard Newman [:rnewman]]

This PR does two things:

* We checkpoint immediately after futzing with tables. This gets the result out of the WAL and into the main DB structure, which can only be a good thing, and will help to keep the WAL small.

* We finalize statements as soon as we're done with them, rather than waiting for the deinitializer to run. Shorter lifespans are nice.

Comment 3

[Richard Newman [:rnewman]]

As a follow-up we should consider checkpointing manually when it's convenient. We'll probably do so after each sync.

Comment 4

[Stephan Leroux [:sleroux]]

I haven't used WAL journaling before but it looks interesting. From what I read, instead of performing transactions to the DB directly and have a fallback, commits are written to the WAL file and then when a checkpoint is reached or invoked, the WAL is written to the DB. Is that correct? I won't hijack this bug for this discussion but I'd be interested in learning more about this.

Comment 5

[Richard Newman [:rnewman]]

Pretty much. Writers write to the WAL, not directly to the DB file; this buys some concurrency and some more resilience.

After some amount of writing, the WAL is checkpointed, which involves replaying some or all of it directly into the DB.

It's hard to describe it better than sqlite's docs do:

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

Main concerns with the WAL are the cost of futzing with a large one next time you open the DB, and the size it can occupy on disk -- without taking some care, it can temporarily bloat, and it won't be resized down.

Comment 6

[Richard Newman [:rnewman]]

https://github.com/mozilla/firefox-ios/commit/608d139a4e81456ac95550ca40a47b95fb35362e