Do you test for the backup errors, i.e. SQLITE_BUSY and SQLITE_LOCKED? Do you test for step errors, i.e. SQLITE_BUSY?
If you get the busy error, you can wait a while and try again or start over. /Patrik On 08/24/2012 05:46 PM, Jonathan Engle wrote: > Ran into this recently, it's happened on one machine running a beta test of > our software. This is a multi-threaded application, and I've run into a > sequence of steps that deadlocks hard that as far as I can tell from the > documentation shouldn't. > This is using SQLite 3.7.13 with SEE. > The source database is using WAL mode, all transactions are done as > IMMEDIATE, synchronous mode is set to 0, and it is encrypted. > The destination database for the backup is not encrypted, and is default > (non-WAL, full synchronous) modes. > > > There are multiple threads active: > > - one performing a write > - two performing reads > - one closing a connection > - one is in the middle of a backup operation > > Here are the call stacks for the threads: > > > Writing thread: > > sqlite3_step > sqlite3VdbeExec > sqlite3VdbeHalt > sqlite3BtreeCommitPhaseOne > sqlite3PagerCommitPhaseOne > pagerWalFrames > sqlite3BackupUpdate > backupOnePage > sqlite3BtreeEnter > lockBtreeMutex > pthread_mutex_lock > __psynch_mutexwait > > Closing a connection thread: > > sqlite3_close > sqlite3BtreeEnterAll > sqlite3BtreeEnter > lockBtreeMutex > pthread_mutex_lock > __psynch_mutexwait > > Reading thread: > > sqlite3_step > sqlite3VdbeExec > sqlite3VdbeEnter > sqlite3BtreeEnter > lockBtreeMutex > pthread_mutex_lock > __psynch_mutexwait > > Backing up thread: > > sqlite3_backup_step > sqlite3BtreeEnter > lockBtreeMutex > pthread_mutex_lock > __psynch_mutexwait > > Reading thread: > > sqlite3_step > sqlite3VdbeExec > sqlite3VdbeEnter > sqlite3BtreeEnter > lockBtreeMutex > pthread_mutex_lock > __psynch_mutexwait > > > > Also, the destination database for the backup is created on the stack by the > the thread doing the backup and is never passed out to anybody (explicitly). > > What looks like is happening to me is that the writing and backing-up thread > are deadlocking with each other, with 'sqlite3BackupUpdate' attempting to > update the backup destination database. Unfortunately, this is not something > I've reproduced locally, so I can't look parameters or lock states. I'm > going to try, as a kind of hail-mary, putting a BEGIN IMMEDIATE transactions > around the backup to block writing during the database backup. > > If anyone has any suggestions or ideas about what I might be doing wrong > here, I'd appreciate it. > > > _______________________________________________ > 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
