Hi everyone, I'm trying to understand what's going on in sqlite starting from version 3.7.11 when a transaction rolls back and there are pending statements.
The changelog for 3.7.11 states: Pending statements no longer block ROLLBACK. Instead, the pending statement > will return SQLITE_ABORT upon next access after the ROLLBACK. > In a simpe minimal test case I confirmed that rolling back a transaction indeed "breaks" a pending statement (I was using a prepared statement). However, the lock that's aquired by a statement doesn't seem to get released on ROLLBACK. What I do essentially: - begin a regular transaction - prepare a SELECT-statement that reads from a table with many rows (sqlite3_prepare) - execute a statement once (sqlite3_step()) [*shared lock aquired here*] - rollback a transaction (ROLLBACK + END) [*shared lock expected to be released here but doesn't?*] In order to confirm that there is a lock on a database I try two things: - Run `lsof test.db` and confirm that there is a read lock flag in FD column - To double check, I open the database in CLI and try to execute a modifying statement (which fails) If it's not just me, is this intended behavior? To me it would make sense to release any locks aquired by pending statements since they get unusable anyway. P.S. I tried this with SQLite v3.7.15.2 Related threads: [BUG] sqlite3_exec "BEGIN; ROLLBACK" corrupts statement already running<http://sqlite.1065341.n5.nabble.com/BUG-sqlite3-exec-quot-BEGIN-ROLLBACK-quot-corrupts-statement-already-running-td63874.html> -- Dmitry Pashkevich _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
