Recent News

SQLite version 3.6.16 is another general maintenance relase containing
performance and robustness enhancements. A single notable bug was fixed
(ticket #3929). This bug cause cause INSERT or UPDATE statements to fail
on indexed tables that have AFTER triggers that modify the same table and
index.

SQLite version 3.6.14.2 fixes an obscure bug in the code generator
(ticket #3879)
section of SQLite which can potentially cause incorrect query results.
The changes from the prior release consist of only this one bug fix,
check-in [6676]
and a change to the version number text.

The bug was introduced in version 3.6.14. It is recommended that
users of version 3.6.14 and 3.6.14.1 upgrade to this release. Applications
are unlikely to hit this bug, but since it is difficult to predict which
applications might hit it and which might not, we recommend that all
users of 3.6.14 and 3.5.14.1 upgrade to this release.

SQLite version 3.6.14 provides new performance enhancements in
the btree and pager layers and in the query optimizer. Certain
workloads can be as much as twice as fast as the previous release,
though 10% faster is a more typical result.

Queries against virtual tables that contain OR and IN operators
in the WHERE clause are now able to use indexing.

A new optional asynchronous I/O backend is available for
unix and windows. The asynchronous backend gives the illusion of faster
response time by pushing slow write operations into a background thread.
The tradeoff for faster response time is that more memory is required
(to hold the content of the pending writes) and if a power failure or
program crash occurs, some transactions that appeared to have committed
might end up being rolled back upon restart.

This release also contains many minor bug fixes, documentation enhancements,
new test cases, and cleanups and simplifications to the source code.

There is no compelling reason to upgrade from versions 3.6.12 or
3.6.13 if those prior versions are working. Though many users may
benefit from the improved performance.

SQLite version 3.6.12 fixes a database corruption bug. If an
incremental_vacuum is rolled back in an in-memory database, the
database will often go corrupt. This only happens for in-memory
databases. On-disk databases are unaffected. And the corruption
only appears if an incremental vacuum is rolled back. Nevertheless,
upgrading is recommended for all applications, especially those that
make use of in-memory databases and/or incremental vacuum. See ticket #3761.

SQLite version 3.6.11 adds support for the
hot-backup interface. This interface can be
used to create a backup copy of an SQLite database while it is in use.
The same interface can be used to initialize an in-memory database from
a persistent disk image or to save an in-memory database into a
persistent disk image. Usage examples can be found at
Using the SQLite Online Backup API.

SQLite version 3.6.10 fixes a cache coherency bug (Ticket #3584)
introduced by check-in
[5864]
which was part of version 3.6.5. This bug might lead to database
corruption, hence we felt it was important to get it out as quickly
as possible, even though there had already been two prior releases
this week.

Some concern has been expressed that we are releasing too frequently.
(Three releases in one week is a lot!) The concern is that this creates
the impression of volatility and unreliability. We have been told that
we should delay releases in order to create the impression of stability.
But the SQLite developers feel that truth is more important than
perception, not the other way around. We think it is important to make
the highest quality and most stable version of SQLite available to users
at all times. This week has seen two important bugs being discovered
shortly after a major release, and so we have issued two emergency
patch releases after the regularly scheduled major release. This makes
us look bad. This puts "egg on our face." We do not like that. But,
three releases also ensures that the best quality SQLite code base
is available available to you at all times.

It has been suggested that "beta" releases might find these kinds of bugs
prior to a major release. But our experience indicates otherwise.
The two issues that prompted releases 3.6.9 and 3.6.10 were both
discovered by internal testing and review - not by external users.
And, indeed, most the problems found in SQLite these days are discovered
by our rigorous internal testing protocol,
not bug reports from the field.

It has also been argued that we should withhold releases "until testing
is finished." The fallacy there is that we never finish testing. We
are constantly writing new test cases for SQLite and thinking of new
ways to stress and potentially break the code. This is a continuous,
never-ending, and on-going process. All existing tests pass before each
release. But we will always be writing new tests the day after a release,
regardless of how long we delay that release. And sometimes those new
tests will uncover new problems.

All this is to say that we believe that SQLite version 3.6.10 is the
most stable, most thoroughly tested, and bug-free version of SQLite
that has ever existed. Please do not be freaked out by three releases
occurring in one week.

Internal stress testing revealed a corner case where the cost function
on the query optimizer might mislead the query optimizer into making a
poor indexing choice. That choice could then tickle another bug in
the VDBE which might result in an incorrect query result. This
release fixes both problems. The chances of actually hitting this
combination of problems in a real application seems remote.
Nevertheless upgrading is recommended.