On 29 September 2015 at 03:47, Florian Weimer <fw at deneb.enyo.de> wrote:
> Relatively rarely, while starting a transaction on a concurrently > modified SQLite database in WAL mode, I get a SQLITE_BUSY_SNAPSHOT > error for just-prepared "BEGIN IMMEDIATE" statement. > BEGIN IMMEDIATE takes a RESERVED lock straight away, which for WAL mode translates into 1) starting a read transaction and 2) upgrading to a write transaction. I've no practical experience with WAL mode so hopefully someone corrects me if I'm wrong, but the comment on sqlite3WalBeginReadTransaction indicates that the data is snapshotted at this point in time -- if another thread modifies the database while the read transaction is open, the changes will not be visible in this transaction. So even though BEGIN IMMEDIATE is logically one step, there are two WAL operations involved, and if another thread modifies the db in between those operations we are indeed left looking at an out-of-date snapshot, so SQLITE_BUSY_SNAPSHOT seems appropriate regardless of the fact that we haven't read anything yet. -Rowan
