contrib/sqlite3/sqlite3.c

62131 #define WAL_RETRY  (-1)
62234       if( rc==SQLITE_IOERR_SHORT_READ ) rc = WAL_RETRY;
62263 ** WAL_RETRY, then the heap memory wal-index has been discarded and
62289     if( rc==SQLITE_BUSY ) rc = WAL_RETRY;
62299   ** If the shared-memory is now "reliable" return WAL_RETRY, which will
62319     rc = (rc==SQLITE_READONLY ? WAL_RETRY : rc);
62344     rc = (pWal->hdr.mxFrame==0 ? SQLITE_OK : WAL_RETRY);
62355     ** Return WAL_RETRY which will cause the in-memory WAL-index to be
62357     rc = WAL_RETRY;
62372   ** heap-memory wal-index is discarded and WAL_RETRY returned to
62389     ** appended to this wal file. Set rc to WAL_RETRY and break out of
62392       rc = WAL_RETRY;
62416 ** other transient condition.  When that happens, it returns WAL_RETRY to
62433 ** this routine during the current read attempt that returned WAL_RETRY.
62435 ** race conditions after multiple WAL_RETRY returns, and after an excessive
62511       ** then convert BUSY errors to WAL_RETRY.  If recovery is known to
62513       ** which might cause WAL_RETRY to be returned even if BUSY_RECOVERY
62515       ** WAL_RETRY this routine will be called again and will probably be
62520         ** We assume this is a transient condition, so return WAL_RETRY. The
62526         rc = WAL_RETRY;
62529         rc = WAL_RETRY;
62571         return WAL_RETRY;
62619     return rc==SQLITE_BUSY ? WAL_RETRY : SQLITE_READONLY_CANTINIT;
62624     return rc==SQLITE_BUSY ? WAL_RETRY : rc;
62666     return WAL_RETRY;
62801   }while( rc==WAL_RETRY );
63227     }while( rc==WAL_RETRY );