On 09/09/2015 08:48 PM, Matthew Flatt wrote: > The documentation for SQLITE_READONLY_ROLLBACK suggests that it will > only happen as a result of a previous crash or power failure, where a > hot journal is left behind. I'm seeing that error without those events > and with a small number of concurrent readers and writers. > > In the implementation of SQLite, comments in hasHotJournal() mention > the possibility of a false positive (referencing ticket #3883, which I > cannot find) and how it will be handled in the playback mechanism after > obtaining an exclusive lock. The check for a read-only connection after > hasHotJournal() is called, however, happens (and must happen?) before > that exclusive lock is acquired. So, it seems like the race-provoked > false positive could trigger a false SQLITE_READONLY_ROLLBACK error. > > If that's right, then for my application's purposes, it works to detect > SQLITE_READONLY_ROLLBACK and just try again. I'd like to make sure I'm > not missing some other problem in my system, though.
I think your analysis is correct. If you open a database that has a journal file with a read-only connect, stop it here using the debugger: http://www.sqlite.org/src/artifact/4784012f80b21?ln=4875 delete the journal file and then let the process continue, you do indeed get an SQLITE_READONLY_ROLLBACK error. Dan. > > Thanks! > Matthew > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
