Documentation Source Text

Check-in [af7d790e13]
Login

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

Overview
Comment:Improved hyperlinks on various documents.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: af7d790e1309581f78d6eecdc20823cc5a871269
User & Date: drh 2013-05-14 02:37:04
Context
2013-05-14
11:12
Fix a typo in queryplanner.html. check-in: d52ed00775 user: drh tags: trunk
02:37
Improved hyperlinks on various documents. check-in: af7d790e13 user: drh tags: trunk
2013-05-08
18:04
Update the change log. check-in: f88ad9fa6a user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/atomiccommit.in.

  1188   1188   <h2>9.0 Things That Can Go Wrong</h2>
  1189   1189   
  1190   1190   <p>The atomic commit mechanism in SQLite has proven to be robust,
  1191   1191   but it can be circumvented by a sufficiently creative
  1192   1192   adversary or a sufficiently broken operating system implementation.
  1193   1193   This section describes a few of the ways in which an SQLite database
  1194   1194   might be corrupted by a power failure or system crash.
  1195         -(See also: [How To Corrupt Your Database Files].)</p>
         1195  +(See also: [how to corrupt | How To Corrupt Your Database Files].)</p>
  1196   1196   
  1197   1197   <tcl>hd_fragment brokenlocks</tcl>
  1198   1198   <h3>9.1 Broken Locking Implementations</h3>
  1199   1199   
  1200   1200   <p>SQLite uses filesystem locks to make sure that only one
  1201   1201   process and database connection is trying to modify the database
  1202   1202   at a time.  The filesystem locking mechanism is implemented

Changes to pages/changes.in.

   104    104       according to the specified collation and that the comparisons associate with
   105    105       the compound query use the native collation.  Ticket
   106    106       [http://www.sqlite.org/src/info/6709574d2a8d8 | 6709574d2a8d8].
   107    107   <li>Bug fix: Makes sure the [sqlite3_set_authorizer | authorizer] callback gets
   108    108       a valid pointer to the string "ROWID" for the column-name parameter when
   109    109       doing an [UPDATE] that changes the rowid.  Ticket
   110    110       [http://www.sqlite.org/src/info/0eb70d77cb05bb2272 | 0eb70d77cb05bb2272]
          111  +<li>Bug fix: Do not move WHERE clause terms inside OR expressions that are
          112  +    contained within an ON clause of a LEFT JOIN.  Ticket 
          113  +    [http://www.sqlite.org/src/info/f2369304e4 | f2369304e4]
   111    114   }
   112    115   
   113    116   chng {2013-04-12 (3.7.16.2)} {
   114    117   <li>Fix a bug (present since version 3.7.13) that could result in database corruption
   115    118       on windows if two or more processes try to access the same database file at the
   116    119       same time and immediately after third process crashed in the middle of committing
   117    120       to that same file.  See ticket 

Changes to pages/howtocorrupt.in.

   295    295   Internet searches such as "fake capacity usb" will turn up lots of
   296    296   disturbing information about this problem.
   297    297   
   298    298   <h2>5.0 Memory corruption</h2>
   299    299   
   300    300   <p>SQLite is a C-library that runs in the same address space as the 
   301    301   application that it serves.  That means that stray pointers, buffer
   302         -overruns, heap corruption, or other malfunctions in application can
          302  +overruns, heap corruption, or other malfunctions in the application can
   303    303   corrupt internal SQLite data structure and ultimately result in a
   304    304   corrupt database file.  Normally these kinds of problems manifest themselves
   305    305   as segfaults prior to any database corruption occurring, but there have
   306    306   been instances where application code errors have caused SQLite to
   307    307   malfunction subtly so as to corrupt the database file rather than
   308    308   panicking.</p>
   309    309   
          310  +<p>The memory corruption problem becomes more acute when
          311  +using [memory-mapped I/O].
          312  +When all or part of the database file is mapped into the application's
          313  +address space, then a stray pointer the overwrites any part of that
          314  +mapped space will immediately corrupt the database file, without
          315  +requiring the application to do a subsequent write() system call.</p>
          316  +
   310    317   <h2>6.0 Other operating system problems</h2>
   311    318   
   312    319   <p>Sometimes operating systems will exhibit non-standard behavior which
   313    320   can lead to problems.  Sometimes this non-standard behavior is deliberate,
   314    321   and sometimes it is a mistake in the implementation.  But in any event,
   315    322   if the operating performs differently from they way SQLite expects it to
   316    323   perform, the possibility of database corruption exists.</p>
................................................................................
   336    343   the memory obtained from the first mmap() call to be zeroed.  SQLite on
   337    344   unix uses mmap() to create a shared memory region for transaction 
   338    345   coordination in [WAL | WAL mode], and it will call mmap() multiple times
   339    346   for large transactions.  The QNX mmap() has been demonstrated to corrupt
   340    347   database file under that scenario.  QNX engineers are aware of this problem
   341    348   and are working on a solution; the problem may have already been fixed by
   342    349   the time you read this.</p>
          350  +
          351  +<p>When running on QNX, it is recommended that [memory-mapped I/O] never
          352  +be used.  Furthermore, to use [WAL mode], it is recommended that applications
          353  +employ the [locking_mode | exclusive locking mode] in order to 
          354  +use [WAL without shared memory].
   343    355   
   344    356   <h2>7.0 Bugs in SQLite</h2>
   345    357   
   346    358   <p>SQLite is [testing | very carefully tested] to help ensure that it is
   347    359   as bug-free as possible.  Among the many tests that are carried out for
   348    360   every SQLite version are tests that simulate power failures, I/O errors,
   349    361   and out-of-memory (OOM) errors and verify that no database corrupt occurs

Changes to pages/testing.in.

   385    385   contains [testcase macros] to verify that both sides of each boundary
   386    386   have been tested.</p>
   387    387   
   388    388   <tcl>hd_fragment regressiontesting</tcl>
   389    389   <h2>5.0 Regression Testing</h2>
   390    390   
   391    391   <p>Whenever a bug is reported against SQLite, that bug is not considered
   392         -fixed until new test cases have been added to the TCL test suite which
   393         -would exhibit the bug in an unpatched version of SQLite.  Over the years,
   394         -this has resulted in thousands and thousands of new tests being added
   395         -to the TCL test suite.  These regression tests ensure that bugs that have
          392  +fixed until new test cases that would exhibit the bug have been added 
          393  +to either the TCL or TH3 test suites.
          394  +Over the years,
          395  +this has resulted in thousands and thousands of new tests.
          396  +These regression tests ensure that bugs that have
   396    397   been fixed in the past are not reintroduced into future versions of
   397    398   SQLite.</p>
   398    399   
   399    400   <tcl>hd_fragment leakcheck</tcl>
   400    401   <h2>6.0 Automatic Resource Leak Detection</h2>
   401    402   
   402    403   <p>Resource leak occurs when system resources
................................................................................
   413    414   quickly.  SQLite is designed to never leak memory, even after
   414    415   an exception such as an OOM error or disk I/O error.  The test
   415    416   harnesses are zealous to enforce this.</p>
   416    417   
   417    418   <tcl>hd_fragment coverage {test coverage}</tcl>
   418    419   <h2>7.0 Test Coverage</h2>
   419    420   
   420         -<p>The SQLite core has 100% branch test coverage under [TH3] as of
   421         -2009-07-25, in its default configuration as measured by
   422         -[http://gcc.gnu.org/onlinedocs/gcc/Gcov.html | gcov]
   423         -utility on SuSE Linux 10.1 on x86 hardware with the GCC 4.0.1 compiler.</p>
          421  +<p>The SQLite core has 100% branch test coverage under [TH3] in
          422  +its default configuration as measured by
          423  +[http://gcc.gnu.org/onlinedocs/gcc/Gcov.html | gcov].</p>
   424    424   
   425    425   <p>The "SQLite core" in the previous paragraph excludes the
   426    426   operating-system dependent [VFS] backends, since it is
   427    427   not possible to write cross-platform tests for those modules.  Extensions
   428    428   such as FTS3 and RTree are also excluded from the analysis.</p>
   429    429   
   430    430   <tcl>hd_fragment stmtvbr</tcl>

Changes to pages/wal.in.

   380    380   a WAL database without using shared memory if that
   381    381   process is guaranteed to be the only process accessing the database.
   382    382   ^This feature allows WAL databases to be created, read, and written
   383    383   by legacy [VFSes] that lack the "version 2" shared-memory
   384    384   methods xShmMap, xShmLock, xShmBarrier, and xShmUnmap on the
   385    385   [sqlite3_io_methods] object.</p>
   386    386   
   387         -<p>^(If EXCLUSIVE locking mode is set prior to the first WAL-mode 
          387  +<p>^(If [locking_mode | EXCLUSIVE locking mode]
          388  +is set prior to the first WAL-mode 
   388    389   database access, then SQLite never attempts to call any of the
   389    390   shared-memory methods and hence no shared-memory
   390    391   wal-index is ever created.)^
   391    392   ^(In that case, the database connection remains in EXCLUSIVE mode
   392    393   as long as the journal mode is WAL; attempts to change the locking
   393    394   mode using "<tt>PRAGMA locking_mode=NORMAL;</tt>" are no-ops.)^
   394    395   ^The only way to change out of EXCLUSIVE locking mode is to first