Hi, I have an sqlite3 database (version 3.25.3) in tmpfs which has many readers and writers.
The database is running in WAL mode and seems to work efficiently in that mode. Since the database files are in a memory based file-system, we don't care about the usual corruption on power-cycle issues because we rebuild a clean database from scratch when we power up again. 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 to select statements ie. Not attempting to modify the database - The service typically runs for a few minutes trying to read the database about 1-2 times per second before asserting. The service is 'nicer' than the other reader/writers. Each writer is responsible for a distinct subset of the values in the database. ie. Every variable/row in the database has a unique owner that can change the value. There are multiple readers for each variable/row. These response codes are currently treated as cause for assert (accept only SQLITE_OK or SQLITE_DONE responses, assert on all other response codes). The sqlite3 documentation indicates that these errors indicate possible database corruption, the sqlite3 source code comments seem to indicate that they can also occur on race conditions with a writer. Questions: 1) Should we treat these responses as an invitation to retry later rather than asserts? 2) Do these responses indicate that the variable(s) requested in the select have not been returned? ie we need to accept the possibility that the requested values are temporarily unavailable. 3) Are there any configuration settings on the database that might reduce the probability of occurrence? 4) If there aren't any configuration settings, are there any usage patterns to avoid or to embrace? -- Robert Searle Lead Design Engineer Tait Communications DDI: +64 3 3570717 Email: robert.sea...@taitradio.com www.taitradio.com -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer <http://www.taitradio.com/email_disclaimer> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
