Documentation Source Text

<tcl>
set nChng 0
proc chng {date desc {options {}}} {
  global nChng aChng
  set aChng($nChng) [list $date $desc $options]
  incr nChng
}











chng {2016-02-15 (3.11.0)} {
<p><b>General improvements:</b>
<li>Enhanced [WAL mode] so that it works efficiently with transactions that are
    larger than the [cache_size].
<li>Added the [FTS5 detail option].
<li>Added the "EXTRA" option to [PRAGMA synchronous] that does a sync of the

  processing is required, for example to implement stemming or
  discard punctuation, this can be done by creating a tokenizer
  implementation that uses the ICU tokenizer as part of its implementation.

<tcl>hd_fragment unicode61 unicode61</tcl>
<p>
  The "unicode61" tokenizer is available beginning with SQLite [version 3.7.13].
  Unicode61 works very much like "simple" except that it does full 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.

<p>
  By default, "unicode61" also removes all diacritics from Latin script

</td>
<td width="20"></td><td bgcolor="#044a64" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>

<li><a href="releaselog/3_11_0.html">Version 3.11.0</a>
of SQLite is recommended for all new development.
</li>
</ul></p>

<h3>Common Links</h3>

<p><ul>
<li> <a href="features.html">Features</a> </li>

  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  regsub -all {[Tt]icket #(\d+)} $txt \
      {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
  hd_resolve "<blockquote>$txt</blockquote>"
  hd_puts "<hr width=\"50%\">"
}








newsitem {2016-02-15} {Release 3.11.0} {
<p>SQLite [version 3.11.0] is a regularly scheduled maintenance release.
}

newsitem {2016-01-20} {Release 3.10.2} {
<p>Yikes!  An optimization attempt gone bad resulted in a 

subset of the tests currently implemented using TH3.  New test modules are
added on a regular basis.</p>

<h2>5.0 TH3 License</h2>

<p>SQLite itself is in the <a href="copyright.html">public domain</a> 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.</p>

<p>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.</p>

<p>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
of SQLite can deploy their application with the confidence of knowing that
it has been tested using TH3.  They simply cannot rerun those tests

readers might block while the checkpoint is running.

<li><p>
<b>Very large write transactions.</b>
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
once the write transaction completes (assuming there are no other readers
blocking it) but in the meantime, the file can grow very big.

<p>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.

<p>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.
</ul>

<h2>Implementation Of Shared-Memory For The WAL-Index</h2>

<p>The [wal-index] is implemented using an ordinary file that is
mmapped for robustness.  Early (pre-release) implementations of WAL mode
stored the wal-index in volatile shared-memory, such as files created in