On 2/4/2014 11:57 AM, Yuriy Kaminskiy wrote:
Phew. Do you speak C? Enjoy.printf("insert...\r"); fflush(stdout); for(i = 0; i < 1000; i++) { rc = sqlite3_bind_int(ins_sth, 1, i); assert(rc == SQLITE_OK); rc = sqlite3_step(ins_sth); assert(rc == SQLITE_DONE);
As expected, I get an assertion here, on 925th iteration of the loop. Are you seeing something different?
The only thing is that rc == SQLITE_IOERR at this point, and not SQLITE_BUSY as I stated earlier. If I enable extended result codes (see sqlite3_extended_result_codes), then the error is SQLITE_IOERR_BLOCKED. This is actually documented at http://www.sqlite.org/c3ref/busy_handler.html :
The SQLITE_BUSY error is converted to SQLITE_IOERR_BLOCKED when SQLite is in the middle of a large transaction where all the changes will not fit into the in-memory cache. SQLite will already hold a RESERVED lock on the database file, but it needs to promote this lock to EXCLUSIVE so that it can spill cache pages into the database file without harm to concurrent readers. If it is unable to promote the lock, then the in-memory cache will be left in an inconsistent state and so the error code is promoted from the relatively benign SQLITE_BUSY to the more severe SQLITE_IOERR_BLOCKED. This error code promotion forces an automatic rollback of the changes. See the CorruptionFollowingBusyError < http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError > wiki page for a discussion of why this is important.
-- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
