Thanks, Simon. Indeed I did see that option. But I'm concerned about maintaining integrity in the middle of an power-interrupted commit, so I was hoping to leverage WAL's inverted behavior of not modifying the database file directly until checkpoint time. The only thing left to investigate is how WAL handles power loss during the middle of a checkpoint. Normally I believe it's able to recover because the next db open has the -wal file to look at. But not if I'm storing it in-memory.
So I'm thinking I will copy the -wal file to disk before the checkpoint op for safety, and then load it back onto ramdisk after. I suppose I may have to exit WAL mode in order to perform that copy, making checkpointing a very expensive operation for my app. On Fri, 2017-12-29 at 16:48 +0000, Simon Slavin wrote: > > On 29 Dec 2017, at 4:34pm, Ian Freeman <[email protected]> wrote: > > > I see, then what I'm seeing is just normal behavior of the writes > > being > > flushed to disk. I read what I wanted to hear about > > synchronous=NORMAL > > delaying writes to the -wal file. Instead I'm going to see if I can > > move -wal to a ramdisk and see how that will affect db integrity > > with > > power losses at in-opportune times. > > Did you see > > PRAGMA journal_mode = MEMORY > > ? > > Simon. > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
