Hello,

This letter is a help getting you started to finding your error.

There are many SQLITE_IOERR-errors, for example SQLITE_IOERR_NOMEM which
means out of memory.

I have noticed in my application that I sometimes get out of memory when
calling g_string_new() after modifying the whole table, i.e. adding a
new column.

After thinking about what it is I compiled the sqlite-code with
SQLITE_ENABLE_MEMORY_MANAGEMENT and called sqlite3_release_memory()
after doing much change to the database. I haven't got that error since.

Even though this change is relatively recently I have made test
stresses, but as for now it seems to work.

"The sqlite3_release_memory() interface attempts to free N bytes of heap
memory by deallocating non-essential memory allocations held by the
database library."

Line 23566 in sqlite.c v3.7.15.1:
/*
** This routine translates a standard POSIX errno code into something
** useful to the clients of the sqlite3 functions.  Specifically, it is
** intended to translate a variety of "try again" errors into SQLITE_BUSY
** and a variety of "please close the file descriptor NOW" errors into
** SQLITE_IOERR
**
** Errors during initialization of locks, or file system support for locks,
** should handle ENOLCK, ENOTSUP, EOPNOTSUPP separately.
*/

Line 1021 in sqlite.c v3.7.15.1:
#define SQLITE_IOERR_READ              (SQLITE_IOERR | (1<<8))
#define SQLITE_IOERR_SHORT_READ        (SQLITE_IOERR | (2<<8))
#define SQLITE_IOERR_WRITE             (SQLITE_IOERR | (3<<8))
#define SQLITE_IOERR_FSYNC             (SQLITE_IOERR | (4<<8))
#define SQLITE_IOERR_DIR_FSYNC         (SQLITE_IOERR | (5<<8))
#define SQLITE_IOERR_TRUNCATE          (SQLITE_IOERR | (6<<8))
#define SQLITE_IOERR_FSTAT             (SQLITE_IOERR | (7<<8))
#define SQLITE_IOERR_UNLOCK            (SQLITE_IOERR | (8<<8))
#define SQLITE_IOERR_RDLOCK            (SQLITE_IOERR | (9<<8))
#define SQLITE_IOERR_DELETE            (SQLITE_IOERR | (10<<8))
#define SQLITE_IOERR_BLOCKED           (SQLITE_IOERR | (11<<8))
#define SQLITE_IOERR_NOMEM             (SQLITE_IOERR | (12<<8))
#define SQLITE_IOERR_ACCESS            (SQLITE_IOERR | (13<<8))
#define SQLITE_IOERR_CHECKRESERVEDLOCK (SQLITE_IOERR | (14<<8))
#define SQLITE_IOERR_LOCK              (SQLITE_IOERR | (15<<8))
#define SQLITE_IOERR_CLOSE             (SQLITE_IOERR | (16<<8))
#define SQLITE_IOERR_DIR_CLOSE         (SQLITE_IOERR | (17<<8))
#define SQLITE_IOERR_SHMOPEN           (SQLITE_IOERR | (18<<8))
#define SQLITE_IOERR_SHMSIZE           (SQLITE_IOERR | (19<<8))
#define SQLITE_IOERR_SHMLOCK           (SQLITE_IOERR | (20<<8))
#define SQLITE_IOERR_SHMMAP            (SQLITE_IOERR | (21<<8))
#define SQLITE_IOERR_SEEK              (SQLITE_IOERR | (22<<8))
#define SQLITE_IOERR_DELETE_NOENT      (SQLITE_IOERR | (23<<8))

Best Regards,
Patrik


On 02/10/2013 05:28 PM, Greg Janée wrote:
> Hello, I'm running a web service that uses SQLite that throws a disk I/O
> exception every once in a while, meaning once every few weeks.
> 
> Details: SQLite 3.7.0.1, being called from an Apache/Django/Python
> multi-threaded application running on Solaris 10.  The database file is
> on a local filesystem, and is <200MB.  Disk space is not an issue on
> that filesystem.
> 
> Everything appears fine, and then one transaction out of the blue gets a
> disk I/O error when doing a "BEGIN IMMEDIATE".  The database passes an
> integrity check.  These disk I/O errors don't seem to correlate with
> anything.  When one happens, there isn't a lot of activity on the system
> (individual transactions occurring once every few seconds, say, so
> threading/locking/contention wouldn't seem to be an issue), and the
> transactions immediately before and after the failed transaction
> succeeded just fine.  If there is any correlation, they all seem to
> happen in the middle of the night.  I've checked with my sysadmin, and
> he can't think of anything (backups, virus scans, etc.) that might be
> happening at that time.
> 
> I've searched for help on this topic and have come up with nothing.  It
> should be clear from the above that directory permissions are not the
> problem.
> 
> Any ideas?  Unfortunately, the (standard) Python SQLite wrapper I'm
> using doesn't provide access to any more information (if there is any to
> be had).
> 
> Thanks in advance,
> -Greg
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to