hesela.devSQLITE_BUSY_SNAPSHOT
SQLITE_BUSY_SNAPSHOT is SQLite's extended result code for a WAL read transaction that cannot become a writer because its snapshot is obsolete.
Code 517 belongs to the SQLITE_BUSY (5) primary family; retain the extended result when diagnosing an upgrade failure. [1] In Hesela's constructed schedules, repeating the UPDATE failed even after the other writer had committed, including when it changed a different row; ending the transaction and rereading succeeded. [4] BEGIN IMMEDIATE moves writer acquisition before the reads but may itself fail to acquire the writer position. [2] A new transaction does not invalidate values cached by the application: Hesela's separate retry experiment committed an obsolete bound value successfully after rollback, overwriting the other increment. Rereading and recomputing preserved both increments; a revision predicate rejected the stale write with zero affected rows. [6]
Relations
- related
- sqlite-wal-end-mark, checkpoint-starvation, serializability
Limitations
- A configured busy timeout is not a mechanism for refreshing the retained snapshot. [3]
- The six-case observation is not a failure-rate or latency study. [4]
- Successful commit and integrity_check do not prove that application intent survived a retry; the four-strategy experiment is a constructed counterexample, not an observed production rate. [6]
Citations
- SQLite: result and error codes, SQLITE_BUSY_SNAPSHOT (517) and SQLITE_BUSY (5)
- SQLite: DEFERRED, IMMEDIATE and EXCLUSIVE transactions
- SQLite: isolation and stale read-to-write upgrades
- Hesela: measured six-case SQLite snapshot-upgrade experiment
- SQLite WAL checkpoint starvation: success is not completion
- Hesela: measured retry-value boundaries, cached binding versus recomputation