Documentation Source Text

Check-in [ef14f9a3d4]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:News updates for the 3.7.6.3 release.
Timelines: family | ancestors | descendants | both | branch-3.7.6
Files: files | file ages | folders
SHA1:ef14f9a3d4f10679aea15f0e4c527111ab1f3f48
User & Date: drh 2011-05-19 14:45:17
Context
2011-05-19
17:14
Merge the 3.7.6.3 changes into trunk. check-in: 6800ff0968 user: drh tags: trunk
14:45
News updates for the 3.7.6.3 release. Leaf check-in: ef14f9a3d4 user: drh tags: branch-3.7.6
12:59
Preparing for the 3.7.6.3 patch release. check-in: f3ea1f0a36 user: drh tags: branch-3.7.6
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/news.in.

11
12
13
14
15
16
17
18
19
20
21
22
23

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
...
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
    regsub -all {(Version) (\d+)\.(\d+)\.(\d+)} $title \
      {<a href="releaselog/\2_\3_\4.html">\0</a>} title
  }
  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 "<p>$txt</p>"
  hd_puts "<hr width=\"50%\">"
}

newsitem {2011-May-19} {Version 3.7.6.3} {
  SQLite [version 3.7.6.3] is a patch release that fixes a 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 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 the bug does <u>not</u> cause database corruption.  It is
  as if [ROLLBACK] were being run instead of [COMMIT] in some cases.

  Here is a detailed description of the bug:


  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,
  every changed page for the transaction has 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 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.
}

newsitem {2010-Mar-30} {Version 3.6.23.1} {
  SQLite [version 3.6.23.1] is a patch release to fix a bug in the
  offsets() function of [FTS3] at the request of the Mozilla.  
}

newsitem {2010-Mar-09} {Version 3.6.23} {
  SQLite [version 3.6.23] is a regular bimonthly release of SQLite.
  Upgrading from the prior release is purely optional.

  This release contains new pragmas: the [secure_delete pragma], and
  the [compile_options pragma].
  There are a new SQL functions: [sqlite_compileoption_used()]
  and [sqlite_compileoption_get()].
  New C/C++ interfaces: [sqlite3_compileoption_used()],
  [sqlite3_compileoption_get()], [SQLITE_CONFIG_LOG], and
  [sqlite3_log()].

  This release also includes several minor bug fixes and performance
  improvements.  Support for [SQLITE_OMIT_FLOATING_POINT] is enhanced.
  There are on-going improvements to [FTS3].

  The ".genfkey" command in the [Command Line Interface] has been
  removed.  SQLite has supported standard SQL [foreign key constraints]
  since [version 3.6.19] and so the ".genfkey" command was seen as
  an anachronism.
}

newsitem {2010-Jan-06} {Version 3.6.22} {
  SQLite [version 3.6.22] is a bug-fix release.  Two bugs have been fixed
  that might cause incorrect query results.  
  <ul>
  <li>Ticket [http://www.sqlite.org/src/info/31338dca7e | 31338dca7e]
  describes a
  problem with queries that have a WHERE clause of the form (x AND y) OR z
  where x and z come from one table of a join and y comes from a different
  table.
  <li> Ticket [http://www.sqlite.org/src/info/eb5548a849 | eb5548a849]
  describes
  a problem where the use of the CAST operator in the WHERE clause can lead
  to incorrect results if the column being cast to a new datatype is also
  used in the same WHERE clause without being cast.
  </ul>
  Both bugs are obscure,
  but because they could arise in an application after deployment, it is
  recommended that all applications upgrade SQLite to version 3.6.22.

  This release also includes other minor bug fixes and performance
  enhancements, especially in the [FTS3] extension.
}

</tcl>

<a href="oldnews.html">Old news...</a>







|




|
>










|






<
|


<
>
>









|







 







<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<



11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

42
43
44

45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
...
247
248
249
250
251
252
253


















































254
255
256
    regsub -all {(Version) (\d+)\.(\d+)\.(\d+)} $title \
      {<a href="releaselog/\2_\3_\4.html">\0</a>} title
  }
  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 {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 <u>not</u> cause database corruption.  It is
  as if [ROLLBACK] were being run instead of [COMMIT] in some cases.


  <b>Bug Details</b>

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



















































</tcl>

<a href="oldnews.html">Old news...</a>

Changes to pages/oldnews.in.

3
4
5
6
7
8
9
10
11
12
13



















































14
15
16
17
18
19
20

<tcl>
proc newsitem {date title text} {
  regsub -all {[^a-z0-9]} $date _ tag
  hd_puts "<a name=\"$tag\"></a>"
  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  hd_resolve "<p>$txt</p>"
  hd_puts "<hr width=\"50%\">"
}





















































newsitem {2009-Dec-07} {Version 3.6.21} {
  SQLite [version 3.6.21] focuses on performance optimization.  For
  a certain set of traces, this version uses 12% fewer CPU instructions
  than the previous release (as measured by Valgrind).  In addition, the
  [FTS3] extension has been through an extensive cleanup and rework and
  the [sqlite3_trace()] interface has been modified to insert 







|



>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

<tcl>
proc newsitem {date title text} {
  regsub -all {[^a-z0-9]} $date _ tag
  hd_puts "<a name=\"$tag\"></a>"
  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  hd_resolve "<blockquote>$txt</blockquote>"
  hd_puts "<hr width=\"50%\">"
}


newsitem {2010-Mar-30} {Version 3.6.23.1} {
  SQLite [version 3.6.23.1] is a patch release to fix a bug in the
  offsets() function of [FTS3] at the request of the Mozilla.  
}

newsitem {2010-Mar-09} {Version 3.6.23} {
  SQLite [version 3.6.23] is a regular bimonthly release of SQLite.
  Upgrading from the prior release is purely optional.

  This release contains new pragmas: the [secure_delete pragma], and
  the [compile_options pragma].
  There are a new SQL functions: [sqlite_compileoption_used()]
  and [sqlite_compileoption_get()].
  New C/C++ interfaces: [sqlite3_compileoption_used()],
  [sqlite3_compileoption_get()], [SQLITE_CONFIG_LOG], and
  [sqlite3_log()].

  This release also includes several minor bug fixes and performance
  improvements.  Support for [SQLITE_OMIT_FLOATING_POINT] is enhanced.
  There are on-going improvements to [FTS3].

  The ".genfkey" command in the [Command Line Interface] has been
  removed.  SQLite has supported standard SQL [foreign key constraints]
  since [version 3.6.19] and so the ".genfkey" command was seen as
  an anachronism.
}

newsitem {2010-Jan-06} {Version 3.6.22} {
  SQLite [version 3.6.22] is a bug-fix release.  Two bugs have been fixed
  that might cause incorrect query results.  
  <ul>
  <li>Ticket [http://www.sqlite.org/src/info/31338dca7e | 31338dca7e]
  describes a
  problem with queries that have a WHERE clause of the form (x AND y) OR z
  where x and z come from one table of a join and y comes from a different
  table.
  <li> Ticket [http://www.sqlite.org/src/info/eb5548a849 | eb5548a849]
  describes
  a problem where the use of the CAST operator in the WHERE clause can lead
  to incorrect results if the column being cast to a new datatype is also
  used in the same WHERE clause without being cast.
  </ul>
  Both bugs are obscure,
  but because they could arise in an application after deployment, it is
  recommended that all applications upgrade SQLite to version 3.6.22.

  This release also includes other minor bug fixes and performance
  enhancements, especially in the [FTS3] extension.
}


newsitem {2009-Dec-07} {Version 3.6.21} {
  SQLite [version 3.6.21] focuses on performance optimization.  For
  a certain set of traces, this version uses 12% fewer CPU instructions
  than the previous release (as measured by Valgrind).  In addition, the
  [FTS3] extension has been through an extensive cleanup and rework and
  the [sqlite3_trace()] interface has been modified to insert