Index: third_party/sqlite/sqlite-src-3080704/doc/vfs-shm.txt |
diff --git a/third_party/sqlite/sqlite-src-3080704/doc/vfs-shm.txt b/third_party/sqlite/sqlite-src-3080704/doc/vfs-shm.txt |
deleted file mode 100644 |
index c1f125a12036448001be73772ac7eefcff82095f..0000000000000000000000000000000000000000 |
--- a/third_party/sqlite/sqlite-src-3080704/doc/vfs-shm.txt |
+++ /dev/null |
@@ -1,130 +0,0 @@ |
-The 5 states of an historical rollback lock as implemented by the |
-xLock, xUnlock, and xCheckReservedLock methods of the sqlite3_io_methods |
-objec are: |
- |
- UNLOCKED |
- SHARED |
- RESERVED |
- PENDING |
- EXCLUSIVE |
- |
-The wal-index file has a similar locking hierarchy implemented using |
-the xShmLock method of the sqlite3_vfs object, but with 7 |
-states. Each connection to a wal-index file must be in one of |
-the following 7 states: |
- |
- UNLOCKED |
- READ |
- READ_FULL |
- WRITE |
- PENDING |
- CHECKPOINT |
- RECOVER |
- |
-These roughly correspond to the 5 states of a rollback lock except |
-that SHARED is split out into 2 states: READ and READ_FULL and |
-there is an extra RECOVER state used for wal-index reconstruction. |
- |
-The meanings of the various wal-index locking states is as follows: |
- |
- UNLOCKED - The wal-index is not in use. |
- |
- READ - Some prefix of the wal-index is being read. Additional |
- wal-index information can be appended at any time. The |
- newly appended content will be ignored by the holder of |
- the READ lock. |
- |
- READ_FULL - The entire wal-index is being read. No new information |
- can be added to the wal-index. The holder of a READ_FULL |
- lock promises never to read pages from the database file |
- that are available anywhere in the wal-index. |
- |
- WRITE - It is OK to append to the wal-index file and to adjust |
- the header to indicate the new "last valid frame". |
- |
- PENDING - Waiting on all READ locks to clear so that a |
- CHECKPOINT lock can be acquired. |
- |
- CHECKPOINT - It is OK to write any WAL data into the database file |
- and zero the last valid frame field of the wal-index |
- header. The wal-index file itself may not be changed |
- other than to zero the last valid frame field in the |
- header. |
- |
- RECOVER - Held during wal-index recovery. Used to prevent a |
- race if multiple clients try to recover a wal-index at |
- the same time. |
- |
- |
-A particular lock manager implementation may coalesce one or more of |
-the wal-index locking states, though with a reduction in concurrency. |
-For example, an implemention might implement only exclusive locking, |
-in which case all states would be equivalent to CHECKPOINT, meaning that |
-only one reader or one writer or one checkpointer could be active at a |
-time. Or, an implementation might combine READ and READ_FULL into |
-a single state equivalent to READ, meaning that a writer could |
-coexist with a reader, but no reader or writers could coexist with a |
-checkpointer. |
- |
-The lock manager must obey the following rules: |
- |
-(1) A READ cannot coexist with CHECKPOINT. |
-(2) A READ_FULL cannot coexist with WRITE. |
-(3) None of WRITE, PENDING, CHECKPOINT, or RECOVER can coexist. |
- |
-The SQLite core will obey the next set of rules. These rules are |
-assertions on the behavior of the SQLite core which might be verified |
-during testing using an instrumented lock manager. |
- |
-(5) No part of the wal-index will be read without holding either some |
- kind of SHM lock or an EXCLUSIVE lock on the original database. |
- The original database is the file named in the 2nd parameter to |
- the xShmOpen method. |
- |
-(6) A holder of a READ_FULL will never read any page of the database |
- file that is contained anywhere in the wal-index. |
- |
-(7) No part of the wal-index other than the header will be written nor |
- will the size of the wal-index grow without holding a WRITE or |
- an EXCLUSIVE on the original database file. |
- |
-(8) The wal-index header will not be written without holding one of |
- WRITE, CHECKPOINT, or RECOVER on the wal-index or an EXCLUSIVE on |
- the original database files. |
- |
-(9) A CHECKPOINT or RECOVER must be held on the wal-index, or an |
- EXCLUSIVE on the original database file, in order to reset the |
- last valid frame counter in the header of the wal-index back to zero. |
- |
-(10) A WRITE can only increase the last valid frame pointer in the header. |
- |
-The SQLite core will only ever send requests for UNLOCK, READ, WRITE, |
-CHECKPOINT, or RECOVER to the lock manager. The SQLite core will never |
-request a READ_FULL or PENDING lock though the lock manager may deliver |
-those locking states in response to READ and CHECKPOINT requests, |
-respectively, if and only if the requested READ or CHECKPOINT cannot |
-be delivered. |
- |
-The following are the allowed lock transitions: |
- |
- Original-State Request New-State |
- -------------- ---------- ---------- |
-(11a) UNLOCK READ READ |
-(11b) UNLOCK READ READ_FULL |
-(11c) UNLOCK CHECKPOINT PENDING |
-(11d) UNLOCK CHECKPOINT CHECKPOINT |
-(11e) READ UNLOCK UNLOCK |
-(11f) READ WRITE WRITE |
-(11g) READ RECOVER RECOVER |
-(11h) READ_FULL UNLOCK UNLOCK |
-(11i) READ_FULL WRITE WRITE |
-(11j) READ_FULL RECOVER RECOVER |
-(11k) WRITE READ READ |
-(11l) PENDING UNLOCK UNLOCK |
-(11m) PENDING CHECKPOINT CHECKPOINT |
-(11n) CHECKPOINT UNLOCK UNLOCK |
-(11o) RECOVER READ READ |
- |
-These 15 transitions are all that needs to be supported. The lock |
-manager implementation can assert that fact. The other 27 possible |
-transitions among the 7 locking states will never occur. |