On Mon, Feb 1, 2016 at 9:55 AM, Adam Devita <adevita at verifeye.com> wrote:
> At the risk of repeating something mentioned last week on this thread. > One tactic to reduce/avoid the no-directory sync problem is to use WAL > mode. The commit in WAL is write to the WAL file, so the the directory > sync problem goes away. > Further, if durability is important to your application, there are truncate and persist options in addition to delete that might be more effective for a particular use case. Again, as I suggested last night (somewhat tongue in cheek) we could have a paranoid journal mode that does persist, truncate and delete in that order. > If you want to be in paranoid mode, don't trust others. Why not use > the backup api before checkpointing and after the checkpoint has > succeeded, check that both dbs have the same state before deleting (or > archiving) the backup? > In this case you aren't necessarily ahead because if the information is cached in RAM but not flushed to disk, you could (theoretically) get a 100% match yet not have the bits of either file truly synced to disk. > Another tactic to handle that hasn't been discussed (if memory serves > me) that I'm curious if the following would work to get around the > directory sync issue: > Separate Sqlite telling your program that the transaction is done > from the program telling the user. Don't tell the *user* that the > transaction is done until you have confirmed the .journal file that > existed before your commit no longer exists after it, so a power off > rollback can't happen. Could the OS lie and say the .journal file has > been deleted only to have it re-appear if the power failure is at the > 'wrong' time? > Isn't that the exact nature of the problem being discussed? Journal is deleted, hard power loss occurs, and journal file still exists when the OS next powers up and looks for the journal file? -- Scott Robison
