Robert Searle wrote: > We have recently started trying to provide read-only access to the database > (service run as user with group/other read access permissions under Linux, > service not database owner) and occasionally get either > SQLITE_READONLY_RECOVERY or SQLITE_READONLY_CANTINIT responses
<https://www.sqlite.org/rescode.html> says: | The SQLITE_READONLY_RECOVERY error code indicates that a WAL mode | database cannot be opened because the database file needs to be | recovered and recovery requires write access but only read access is | available. | The SQLITE_READONLY_CANTINIT result code originates in the xShmMap | method of a VFS to indicate that the shared memory region used by WAL | mode exists buts its content is unreliable and unusable by the current | process since the current process does not have write permission on | the shared memory region. > 1) Should we treat these responses as an invitation to retry later rather > than asserts? Waiting might work if some other process opens the database and actually does the recovery. > 2) Do these responses indicate that the variable(s) requested in the select > have not been returned? Error codes indicate that the call failed. The query did not even begin to execute. > 3) Are there any configuration settings on the database that might reduce > the probability of occurrence? Open the database with write access (so that recovery can be done), but set PRAGMA query_only. > 4) If there aren't any configuration settings, are there any usage patterns > to avoid or to embrace? Don't corrupt the database in the first place. ;-) You aren't using WAL over a network, or across a VM boundary, are you? Normally, recovery is needed if some writer crashes. Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
