proc newsitem {date title text} {
regsub -all {[^a-z0-9]} [string tolower $date] _ tag
hd_puts ""
if {![regsub -all {(Version) (\d+)\.(\d+)\.(\d+)\.(\d+)} $title \
{\0} title]} {
regsub -all {(Version) (\d+)\.(\d+)\.(\d+)} $title \
{\0} title
}
hd_puts "$date - $title
"
regsub -all "\n( *\n)+" $text "\n\n" txt
regsub -all {[Tt]icket #(\d+)} $txt \
{\0} txt
hd_resolve "
$txt
"
hd_puts "
"
}
newsitem {2011-June-28} {Version 3.7.7.1} {
SQLite [version 3.7.7.1] adds a one-line bug fix to 3.7.7 to fix
[http://www.sqlite.org/src/info/25ee812710 | a problem]
causing [PRAGMA case_sensitive_like] statements compiled using the legacy
[sqlite3_prepare()] interface to fail with an [SQLITE_SCHEMA] error. Because
[sqlite3_exec()] uses sqlite3_prepare() internally, the problem also affects
sqlite3_exec().
Upgrading from 3.7.7 is only required for applications that use "PRAGMA
case_sensitive_like" and the sqlite3_prepare() (or sqlite3_exec()) interface.
}
newsitem {2011-June-24} {Version 3.7.7} {
SQLite [version 3.7.7] is a regularly scheduled bi-monthly maintenance
release. Upgrading from version 3.7.6.3 is optional. Upgrading from all
prior releases is recommended.
This release adds support for naming database files using [URI filenames].
URI filenames are disabled by default (for backwards compatibility) but
applications are encouraged to enable them since incompatibilities are
likely to be exceedingly rare and the feature is useful. See the
[URI filenames | URI filename documentation] for details.
Most of the other enhancements in this release involve
[virtual tables]. The virtual table interface has been enhanced to
support [SAVEPOINT] and [ON CONFLICT] clause processing, and the built-in
[RTREE] and [FTS3 | FTS3/FTS4] have been augmented to take advantage of
the new capability. This means, for example, that it is now possible
to use the [REPLACE] command on [FTS3 | FTS3/FTS4] and [RTREE] tables.
The [FTS4] full-text index extension has been enhanced to support
the [FTS4 prefix option] and the [FTS4 order option]. These two enhancements
are provided in support of search-as-you-type interfaces where search
results begin to appear after the first keystroke in the "search" box
and are refined with each subsequent keystroke. The way this is done is
to do a separate full-text search after each key stroke, and add the
"*" wildcard at the end of the word currently being typed. So, for
example, if the text typed so far is "fast da" and the next character
typed is "t", then the application does a full-text search of the
pattern "fast dat*" and displays the results. Such capability has
always existed. What is new is that the [FTS4 prefix option] allows
the search to be very fast (a matter of milliseconds) even for difficult
cases such as "t*" or "th*".
There has been a fair amount of work done on the FTS4 module for this
release. But the core SQLite code has changed little and the previous
release has not given any problems, so we expect this to be a very
stable release.
}
newsitem {2011-May-19} {Version 3.7.6.3} {
SQLite [version 3.7.6.3] is a patch release that fixes a
[http://www.sqlite.org/src/info/2d1a5c67df | single bug]
associated with [WAL mode]. The bug has been in SQLite ever since WAL
was added, but the problem is very obscure and so nobody has noticed
before now. Nevertheless, all users are encouraged to upgrade to
version 3.7.6.3 or later.
The bug is this:
If the [cache_size] is set very small (less than 10) and SQLite comes
under memory pressure and if a multi-statement transaction is started
in which the last statement prior to COMMIT is a SELECT statement and if
a [checkpoint] occurs right after the transaction commit, then
it might happen that the transaction will be silently rolled back instead
of being committed.
The default setting for [cache_size] is 2000. So in most situations, this
bug will never appear. But sometimes programmers set [cache_size] to
very small values on gadgets and other low-memory devices in order to
save memory space. Such applications are vulnerable.
Note that this bug does not cause database corruption. It is
as if [ROLLBACK] were being run instead of [COMMIT] in some cases.
Bug Details
Transactions commit in WAL mode by adding a record onto the end of
the WAL (the write-ahead log) that contains a "commit" flag. So to
commit a transaction, SQLite takes all the pages that have changed
during that transaction, appends them to the WAL, and sets the commit
flag on the last page. Now, if SQLite comes under memory pressure, it
might try to free up memory space by writing changed pages to the WAL
prior to the commit. We call this "spilling" the cache to WAL. There
is nothing wrong with spilling cache to WAL. But if the
memory pressure is severe, it might be that by the time [COMMIT] is run,
all changed pages for the transaction have already been spilled to WAL
and there are no pages left to be written to WAL.
And with no unwritten pages, there was nothing to put the commit flag
on. And without a commit flag, the transaction would end up being
rolled back.
The fix to this problem was that if all changed pages has already
been written to the WAL when the commit was started, then page 1 of
the database will be written to the WAL again, so that there will always
be a page available on which to set the commit flag.
}
newsitem {2011-April-17} {Version 3.7.6.2} {
SQLite [version 3.7.6.2] adds a one-line bug fix to 3.7.6.1 that enables
pthreads to work correctly on NetBSD. The problem was a faulty function
signature for the open system call. The problem does not appear to have
any adverse impact on any system other than NetBSD.
Upgrading from version 3.7.6.1 is only needed on NetBSD.
}
newsitem {2011-April-13} {Version 3.7.6.1} {
SQLite [version 3.7.6.1] fixes a single bug in 3.7.6 that can cause a
segfault if [SQLITE_FCNTL_SIZE_HINT] is used on a unix build that has
SQLITE_ENABLE_LOCKING_MODE set to 0 and is compiled with
HAVE_POSIX_FALLOCATE.
Upgrading from 3.7.6 is only needed for users effected by the
configuration-specific bug described above. There are no other changes
to the code.
}
newsitem {2011-April-12} {Version 3.7.6} {
SQLite [version 3.7.6] is a regularly scheduled bi-monthly maintenance
release of SQLite. Upgrading from version 3.7.5 is optional. Upgrading
releases prior to 3.7.5 is recommended.
}
newsitem {2011-February-01} {Version 3.7.5} {
SQLite [version 3.7.5] is a regularly scheduled bi-monthly maintenance
release of SQLite. Due to the discovery and fix of
[http://www.sqlite.org/src/tktview?name=5d863f876e | an obscure bug]
that could cause database corruption, upgrading from all prior
releases of SQLite is recommended. This bug was found during code
review and has not been observed in the wild.
This release adds new [SQLITE_DBSTATUS_LOOKASIDE_HIT | opcodes] for the
[sqlite3_db_status()] interface that allow more precise measurement of
how the [lookaside memory allocator] is performing, which can be useful
for tuning in applications with very tight memory constraints.
The [sqlite3_vsnprintf()] interface was added. This routine is simply
a varargs version of the long-standing [sqlite3_snprintf()] interface.
The output from [sqlite3_trace()] interface has been enhanced to work
better (and faster) in systems that use recursive extensions such as
[FTS3] or [RTREE].
Testing with Valgrind shows that this release of SQLite is about 1%
or 2% faster than the previous release for most operations.
A fork of the popular ADO.NET adaptor for SQLite known as System.Data.SQLite
is now available on [http://System.Data.SQLite.org/]. The originator
of System.Data.SQLite, Robert Simpson, is aware of this fork, has
expressed his approval, and has commit privileges on the new Fossil
repository. The SQLite development team intends to maintain
System.Data.SQLite moving forward.
}
newsitem {2010-December-08} {Version 3.7.4} {
SQLite [version 3.7.4] is a regularly scheduled bi-monthly maintenance
release of SQLite. Upgrading from [version 3.7.2] and [version 3.7.3]
is optional. Upgrading from all other SQLite releases is recommended.
This release features [full-text search] enhancements. The older
[FTS3] virtual table is still fully supported, and should also run
faster. In addition, the new [FTS4] virtual table is added. FTS4
follows the same syntax as FTS3 but holds additional metadata which
facilitates some performance improvements and more advanced
[matchinfo()] output. Look for further full-text search enhancements
in subsequent releases.
Also in this release, the [EXPLAIN QUERY PLAN] output has been enhanced
and new documentation is provided so that application developers can
more easily understand how SQLite is performing their queries.
Thanks to an account from the folks at [http://www.devio.us/], OpenBSD
has been added to the list of platforms upon which we
[tested | test SQLite] prior to every release. That list of platforms
now includes:
- Linux x86 & x86_64
- MacOS 10.5 & 10.6
- MacOS 10.2 PowerPC
- WinXP and Win7
- Android 2.2
- OpenBSD 4.7
The previous release of SQLite ([version 3.7.3]) has proven to be very
robust. The only serious issue discovered was
[http://www.sqlite.org/src/info/80ba201079 | ticket 80ba201079] that
describes an incorrect query result that can occur under very
unusual circumstances. The ticket description contains details of the
problem. Suffice it to say here that the problem is very obscure and
is unlikely to effect most applications and so upgrading is optional.
The problem is fixed, of course, in this release.
}
newsitem {2010-October-08} {Version 3.7.3} {
SQLite [version 3.7.3] is a regularly scheduled bi-monthly maintenance
release of SQLite. Upgrading from [version 3.7.2] is optional.
Upgrading from all other releases is recommended.
This release adds two new interfaces (really just variations on existing
interfaces). The [sqlite3_create_function_v2()] interface adds a
destructor for the application-data pointer. The new
[sqlite3_soft_heap_limit64()] interface allows the soft heap limit to
be set to a value greater than 231.
The [RTREE] extension has been enhanced with the ability to have an
[custom r-tree queries | application-defined query region]. This might
be used, for example, to locate all objects within
the field of view of a camera.
The 3.7.3 release also includes some performance enhancements, including
query planner improvements, documentation updates,
and fixes to some very obscure bugs.
}
newsitem {2010-August-24} {Version 3.7.2} {
SQLite [version 3.7.2] fixes a long-standing bug that can cause the
database [free-page list] to go corrupt if [incremental_vacuum] is used
multiple times to
partially reduce the size of a database file that contains many hundreds
of unused database pages. The original bug reports together with links
to the patch that fixes it can be seen
here.
This bug has been in the code for at least a year and possibly longer.
The bug has nothing to do with the versions 3.7.1 or 3.7.0 or any other
recent release. The fact that the bug was discovered (and fixed)
within hours of the 3.7.1 release is purely a coincidence.
The bug is impossible to hit without using [incremental_vacuum] and is
very difficult to hit even with incremental_vacuum. And the kind of
corruption that the bug causes can usually be fixed
simply by running [VACUUM]. Nevertheless, because the bug can result
in database corruption, it is recommended that all SQLite users upgrade
to version 3.7.2 or later.
}
newsitem {2010-August-23} {Version 3.7.1} {
SQLite [version 3.7.1] is a stabilization release for the 3.7.x series.
Other than the filesize-in-header bug that was fixed in [version 3.7.0.1],
no major problems have been seen in 3.7.0. Some minor corner-case
performance regressions have been fixed. A typo in the OS/2 interface
has been repaired.
A biggest part of the 3.7.1 release is a cleanup and refactoring of
the pager module within SQLite. This refactoring should have no
application-visible effects. The purpose was to reorganize the code
in ways that make it easier to prove correctness.
The 3.7.1 release adds new experimental methods for obtained more
detailed memory usage information and for controlling database file
fragmentation. And the query planner now does a better job of
optimizing the [LIKE] and [GLOB] operators.
This release increases the maximum size of database pages from 32KiB to
64KiB. A database with 64KiB pages will not be readable or writable by
older versions of SQLite. Note that further increases in page size
are not feasible since the [file format] uses 16-bit offsets to structures
within each page.
}
newsitem {2010-August-04} {Version 3.7.0.1} {
SQLite [version 3.7.0.1] is a patch release to fix a bug in the new
filesize-in-header feature of the [file format | SQLite file format]
that could cause database corruption if the same database file is
written alternately with version 3.7.0 and version 3.6.23.1 or earlier.
A performance regression was also fixed in this release.
}
newsitem {2010-July-22} {Version 3.7.0} {
SQLite [version 3.7.0] is a major release of SQLite that features
a new transaction control mechanism using a [write-ahead log] or [WAL].
The traditional rollback-journal is still used as the default so there
should be no visible change for legacy programs. But newer programs
can take advantage of improved performance and concurrency by enabling
the WAL journaling mode.
SQLite version 3.7.0 also contains some query planner enhancements and
a few obscure bug fixes, but the only really big change is the addition
of WAL mode.
}