General improvements:
The "unicode61" tokenizer is available beginning with SQLite [version 3.7.13]. - Unicode61 works very much like "simple" except that it does full unicode + Unicode61 works very much like "simple" except that it does simple unicode case folding according to rules in Unicode Version 6.1 and it recognizes unicode space and punctuation characters and uses those to separate tokens. The simple tokenizer only does case folding of ASCII characters and only recognizes ASCII space and punctuation characters as token separators. Index: pages/index.in ================================================================== --- pages/index.in +++ pages/index.in @@ -108,12 +108,13 @@
$txt" hd_puts "
SQLite [version 3.11.1] is a patch release that fixes problems in the + new [FTS5] extension and increases a default setting in the [spellfix1] + extension, and implements enhancements to some of the Windows makefiles. + The SQLite core is unchanged from 3.11.0. Upgrading is optional. +} newsitem {2016-02-15} {Release 3.11.0} {
SQLite [version 3.11.0] is a regularly scheduled maintenance release. } Index: pages/th3.in ================================================================== --- pages/th3.in +++ pages/th3.in @@ -306,17 +306,11 @@
SQLite itself is in the public domain and can be used for any purpose. But TH3 is proprietary and requires a license. -Members of the [SQLite Consortium] get free and unlimited access to TH3. -Others can contact the SQLite developers for information on how to obtain -a license to access and use TH3.
- -Licensees of TH3 are given read access to the software configuration -management system used to manage TH3 and so can download the latest version -of TH3 (or any historical version) whenever they like.
+Even though open-source users do not have direct access to TH3, all users of SQLite benefit from TH3 indirectly since each version of SQLite is validated running TH3 on multiple platforms (Linux, Windows, WinRT, Mac, OpenBSD, Solaris Sparc) prior to release. So anyone using an official release Index: pages/wal.in ================================================================== --- pages/wal.in +++ pages/wal.in @@ -418,36 +418,20 @@
Very large write transactions. A checkpoint can only complete when no other transactions are running, which means the WAL file cannot be reset in the middle of a write transaction. So a large change to a large database -might result in a very large WAL file. The WAL file will be checkpointed +might result in a large WAL file. The WAL file will be checkpointed once the write transaction completes (assuming there are no other readers blocking it) but in the meantime, the file can grow very big. -
Note that sometimes the same database page can be written into -the WAL file multiple times within the same transaction, and hence the -WAL file can end up being many times larger than the original database. -This can happen when the [cache_size] is smaller then the number of -database pages changed during the transaction. -When changes are made to a page, those changes are normally held in -memory until the end of the transaction, at which point their are -written to the WAL file. But if the cache fills up, some pages might -need to be spilled to the WAL file before the end of the transaction. -If those same pages change again, then they must be written -to the WAL file again. For a very -large transaction and a small cache, it is possible for the same page -to spill many times and thus be written into the WAL file many times. - -
Defenses against this failure mode include: (1) switching to a -rollback journal modes for large updates since pages are never -written into a rollback journal more than once, (2) making sure that -the [cache_size] is large enough to hold every page that will be changed -during the transaction, -(3) keeping the number of changed pages small by breaking -the transaction up into smaller chunks, and/or (4) dropping indexes before -a large insert and recreating them afterwards. +
As of SQLite version 3.11.0, the WAL file for a single transaction +should be proportional in size to the transaction itself. Pages that +are changed by the transaction should only be written into the WAL file +once. However, with older versions of SQLite, the same page might be +written into the WAL file multiple times if the transaction grows larger +than the page cache.
The [wal-index] is implemented using an ordinary file that is