SQLite version 3.8.7 is a regularly scheduled maintenance release. Upgrading from all prior versions is recommended.
Most of the changes from the previous release have been micro-optimizations designed to help SQLite run a little faster. Each individual optimization has an unmeasurably small performance impact. But the improvements add up. Measured on a well-defined workload (which the SQLite developers use as a proxy for a typical application workload) using cachegrind on Linux and compiled with gcc 4.8.1 and -Os on x64 linux, the current release does over 20% more work for the same number of CPU cycles compared to the previous release. Cachegrind is not a real CPU, and the workload used for measurement is only a proxy. So your performance may vary. We expect to see about half the measured and reported improvement in real-world applications. 10% is less than 20% but it is still pretty good, we think.
This release includes a new set of C-language interfaces that have unsigned 64-bit instead of signed 32-bit length parameters. The new APIs do not provide any new capabilities. But they do make it easier to write applications that are more resistant to integer overflow vulnerabilities.
This release also includes a new sorter that is able to use multiple threads to help with large sort operations. (Sort operations are sometimes required to implement ORDER BY and/or GROUP BY clauses and are almost always required for CREATE INDEX.) The multi-threads sorter is turned off by default and must be enabled using the PRAGMA threads SQL command. Note that the multi-threaded sorter provides faster real-time performance for large sorts, but it also uses more CPU cycles and more energy.
SQLite version 3.8.6 is a regularly scheduled maintenance release. Upgrading from all previous versions is recommended.
This release contains the usual assortment of obscure bug fixes. One bug, however, deserves special attention. A problem appeared in the CREATE INDEX command beginning with version 3.8.2 (2013-12-06) that allowed, under some circumstances, a UNIQUE index to be created on a column that was not unique. Once the index was created, no new non-unique entries could be inserted, but preexisting non-unique entries would remain. See ticket 9a6daf340df99ba93c for further information. In addition to fixing this bug, the PRAGMA integrity_check command has been enhanced to detect non-uniqueness in UNIQUE indices, so that if this bug did introduce any problems in databases, those problems can be easily detected.
Other noteworthy changes include the addition of support for hexadecimal integers (ex: 0x1234), and performance enhancements to the IN operator which, according to mailing list reports, help some queries run up to five times faster.
Version 3.8.6 uses 25% fewer CPU cycles than version 3.8.0 from approximately one year ago, according to valgrind and the test/speedtest1.c test program. On the other hand, the compiled binary for version 3.8.6 is about 5% larger than 3.8.0. The size increase is due in part to the addition of new features such as WITHOUT ROWID tables and common table expressions.
SQLite version 3.8.5 is a regularly scheduled maintenance release. Upgrading from the previous version is recommended.
Version 3.8.5 fixes more than a dozen obscure bugs. None of these bugs should be a problem for existing applications. Nor do any of the bugs represent a security vulnerability. Nevertheless, upgrading is recommended to prevent future problems.
In addition to bug fixes, the 3.8.5 release adds improvements to the query planner, especially regarding sorting using indices and handling OR terms in the WHERE clause for WITHOUT ROWID tables. The ".system" and ".once" dot-commands were added to the command-line interface. And there were enhancements to the FTS4 and RTREE virtual tables. See the change log for details.
The optimizations added in version 3.8.4 caused some queries that involve subqueries in the FROM clause, DISTINCT, and ORDER BY clauses, to give an incorrect result. See ticket 98825a79ce145 for details. This release adds a one-character change to a single line of code to fix the problem.
The code changes that resulted in the performance improvements in version 3.8.4 missed a single buffer overflow test, which could result in a read past the end of a buffer while searching a database that is corrupted in a particular way. Version 188.8.131.52 fixes that problem using a one-line patch.
We are not aware of any problems in version 3.8.4 when working with well-formed database files. The problem fixed by this release only comes up when reading corrupt database files.
Both of these issues came to light within minutes of tagging the previous release. Neither issue is serious but they can be annoying. Hence, the decision was made to do a quick patch release to address both issues.
- Work around a C-preprocessor macro conflict that causes compilation problems for some configurations of Visual Studio.
- Adjust the cost computation for the skip-scan optimization for improved performance.
SQLite version 3.8.4 is a maintenance release featuring performance enhancements and fixes for a number of obscure bugs. There are no significant new features in SQLite version 3.8.4. However, the number of CPU cycles (measured by valgrind) needed to do many common operations has be reduced by about 12% relative to the previous release, and by about 25% relative to version 3.7.16 from approximately one year ago.
Version 3.8.4 of SQLite fixes several corner-case bugs that were found since the previous release. These bugs were unlikely to appear in practice, and none represent a security vulnerability. Nevertheless, developers are encouraged to upgrade from all prior releases.
SQLite version 184.108.40.206 fixes a bug present in versions 3.8.1, 3.8.2 and 3.8.3 that can cause queries to omit valid output rows. Upgrading from those versions is recommended.
The problem only comes up if SQLite is compiled with either the SQLITE_ENABLE_STAT3 or SQLITE_ENABLE_STAT4 compile-time options. In that case, if a query has a WHERE clause that contains expressions like this:WHERE (expr1 OR expr2 OR ... OR exprN) AND column IS NOT NULLWhere all of expr1 through exprN are suitable for use by indexes, then during query planning SQLite might mistakenly converted the "column IS NOT NULL" term into "column>NULL". But the latter term is never true, and so the query would return no rows.
The trouble ticket for this bug is [4c86b126f2]. It is recommended that all users upgrade to avoid this problem.
SQLite version 3.8.3 is a regularly scheduled maintenance release. Upgrading from the previous release is optional.
The most visible change in version 3.8.3 is the addition of support for common table expressions. It is now possible to write a single SELECT statement that will query a tree or graph, using either a depth-first or a breadth-first search. A single SQLite query will even solve Sudoku puzzles or compute the Mandelbrot set. As part of this change, SQLite now accepts a VALUES clause anyplace that a SELECT statement is valid.
This release also includes many small performance enhancements which should give a small speed boost to legacy applications. And there are other minor enhancements such as the addition of the printf() SQL function. See the change log for details.
SQLite version 3.8.2 is a regularly scheduled maintenance release. Upgrading from the previous release is optional.
Version 3.8.2 adds support for WITHOUT ROWID tables. This is a significant extension to SQLite. Database files that contain WITHOUT ROWID tables are not readable or writable by prior versions of SQLite, however databases that do not use WITHOUT ROWID tables are fully backwards and forwards compatible.
The 3.8.2 release contains a potentially incompatible change. In all prior versions of SQLite, a cast from a very large positive floating point number into an integer resulted in the most negative integer. In other words, CAST(+99.9e99 to INT) would yield -9223372036854775808. This behavior came about because it is what x86/x64 hardware does for the equivalent cast in the C language. But the behavior is bizarre. And so it has been changed effective with this release so that a cast from a floating point number into an integer returns the integer between the floating point value and zero that is closest to the floating point value. Hence, CAST(+99.9e99 to INT) now returns +9223372036854775807. Since routines like sqlite3_column_int64() do an implicit cast if the value being accessed is really a floating point number, they are also affected by this change.
Besides the two changes mentioned above, the 3.8.2 release also includes a number of performance enhancements. The skip-scan optimization is now available for databases that have been processed by ANALYZE. Constant SQL functions are now factored out of inner loops, which can result in a significant speedup for queries that contain WHERE clause terms like "date>datetime('now','-2 days')". And various high-runner internal routines have been refactored for reduced CPU load.
SQLite version 3.8.1 is a regularly scheduled maintenance release. Upgrading from the previous release is optional, though you should upgrade if you are using partial indices as there was a bug related to partial indices in the previous release that could result in an incorrect answer for count(*) queries.
The next generation query planner that was premiered in the previous release continues to work well. The new query planner has been tweaked slightly in the current release to help it make better decisions in some cases, but is largely unchanged. Two new SQL functions, likelihood() and unlikely(), have been added to allow developers to give hints to the query planner without forcing the query planner into a particular decision.
Version 3.8.1 is the first SQLite release to take into account the estimated size of table and index rows when choosing a query plan. Row size estimates are based on the declared datatypes of columns. For example, a column of type VARCHAR(1000) is assumed to use much more space than a column of type INT. The datatype-based row size estimate can be overridden by appending a term of the form "sz=NNN" (where NNN is the average row size in bytes) to the end of the sqlite_stat1.stat record for a table or index. Currently, row sizes are only used to help the query planner choose between a table or one of its indices when doing a table scan or a count(*) operation, though future releases are likely to use the estimated row size in other contexts as well. The new PRAGMA stats statement can be used to view row size estimates.
Version 3.8.1 adds the SQLITE_ENABLE_STAT4 compile-time option. STAT4 is very similar to STAT3 in that it uses samples from indices to try to guess how many rows of the index will be satisfy by WHERE clause constraints. The difference is that STAT4 samples all columns of the index whereas the older STAT3 only sampled the left-most column. Users of STAT3 are encouraged to upgrade to STAT4. Application developers should use STAT3 and STAT4 with caution since both options, by design, violate the query planner stability guarantee, making it more difficult to ensure uniform performance is widely-deployed and mass-produced embedded applications.
SQLite version 220.127.116.11 contains a one-line fix to a bug in the new optimization that tries to omit unused LEFT JOINs from a query.
SQLite version 18.104.22.168 fixes some obscure bugs that were uncovered by users in the 3.8.0 release. Changes from 3.8.0 are minimal.
Do not fear the zero!
SQLite version 3.8.0 might easily have been called "3.7.18" instead. However, this release features the cutover of the next generation query planner or NGQP, and there is a small chance of breaking legacy programs that rely on undefined behavior in previous SQLite releases, and so the minor version number was incremented for that reason. But the risks are low and there is a query planner checklist is available to application developers to aid in avoiding problems.
SQLite version 3.8.0 is actually one of the most heavily tested SQLite releases ever. Thousands and thousands of beta copies have be downloaded, and presumably tested, and there have been no problem reports.
SQLite version 3.7.17 is a regularly schedule maintenance release. Visit the change log for a full explanation of the changes in this release.
There are many bug fixes in version 3.7.17. But this does not indicate that 3.7.16 was a problematic release. All of the bugs in 3.7.17 are obscure and are unlikely to impact any particular application. And most of the bugs that are fixed in 3.7.17 predate 3.7.16 and have been in the code for years without ever before being noticed. Nevertheless, due to the large number of fixes, all users are encouraged to upgrade when possible.
SQLite version 22.214.171.124 fixes a long-standing flaw in the Windows OS interface that can result in database corruption under a rare race condition. See http://www.sqlite.org/src/info/7ff3120e4f for a full description of the problem.
As far as we know, this bug has never been seen in the wild. The problem was discovered by the SQLite developers while writing stress tests for a separate component of SQLite. Those stress tests have not yet found any problems with the component they were intended to verify, but they did find the bug which is the subject of this patch release.
Other than updates to version numbers, the only difference between this release and 126.96.36.199 is a two-character change in a single identifier, which is contained in the windows-specific OS interface logic. There are no changes in this release (other than version numbers) for platforms other than Windows.
SQLite version 188.8.131.52 is a bug fix release that fixes a few problems that were present in the previous releases.
The primary motivation for version 184.108.40.206 is to fix a bug in the query optimizer that was introduced as part of version 3.7.15. The query optimizer was being a little overzealous in optimizing out some ORDER BY clauses, which resulted in sorting being omitted on occasions where sorting is required to get the correct answer. See ticket a179fe7465 for details.
In addition to the ORDER BY fix, several other patches to fix obscure (and mostly harmless) bugs and to fix spelling errors in source code comments are also included in this release.
SQLite version 3.7.16 is a regularly scheduled release of SQLite. This release contains several language enhancements and improvements to the query optimizer. A list of the major enhancements and optimizations can be see on the change log.
There was one important bug fix (see Ticket fc7bd6358f) that addresses an incorrect query result that could have occurred in a three-way join where the join constraints compared INTEGER columns to TEXT columns. This issue had been in the code for time out of mind and had never before been reported, so we surmise that it is very obscure. Nevertheless, all users are advised to upgrade to avoid any future problems associated with this issue.
SQLite version 220.127.116.11 is a patch release that fixes a single bug that was introduced in version version 3.7.15. The fix is a 4-character edit to a single line of code. Other than this 4-character change and the update of the version number, nothing has changed from version 18.104.22.168.