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
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
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.

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


This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
sqlite-users mailing list

Reply via email to