On 2/4/2014 5:23 AM, Yuriy Kaminskiy wrote:
How sqlite is supposed to behave when *) there are read-only transaction; *) there are update transaction on other connection; *) cache space is exhausted by update transaction; *) sqlite was not able to upgrade RESERVED lock to EXCLUSIVE due to presence of SHARED lock, even after waiting for busy_timeout; ?
SQLite should return SQLITE_BUSY error for the statement that triggered the cache spill. From the documentation of sqlite3_step:
SQLITE_BUSY means that the database engine was unable to acquire the database locks it needs to do its job. If the statement is a COMMIT or occurs outside of an explicit transaction, then you can retry the statement. If the statement is not a COMMIT and occurs within an explicit transaction then you should rollback the transaction before continuing.
This second part is precisely for the case where a statement other than a COMMIT wants to acquire EXCLUSIVE lock due to cache overflow, and fails. If I recall previous discussions of this topic correctly, SQLite cannot guarantee that the in-memory cache is in a good state at this point, and so the only safe course of action is to discard it by rolling back.
It can either fail update statement (but I don't see that in test below: it sleeps for busy_timeout, but *does not* return error), or keep on storing data in memory [it *does not* write anything] (thus using over specified cache size? [and eventually overflow virtual memory?]), or what?
It's supposed to return an error. There might be some flaw in your test; I myself don't speak Perl (and am too lazy to conduct a test of my own).
-- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
