Documentation Source Text

Check-in [776ba1e766]

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

Comment:Add mention of torn pages to the PSOW document.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 776ba1e7664f91acd096efa2d5eb1aa4fa97c342
User & Date: drh 2012-01-05 12:36:01
Add a note about data types and the compress/uncompress functions to the FTS documentation. (check-in: 8fadbd41ce user: dan tags: trunk)
Add mention of torn pages to the PSOW document. (check-in: 776ba1e766 user: drh tags: trunk)
Updates to the psow and testing documents. (check-in: d30b4960c1 user: drh tags: trunk)
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/

    91     91   is first detected, prior to parking the heads, as long as doing so
    92     92   does not take too long, which it should not with
    93     93   small and dense sectors.  Hence it seems reasonable
    94     94   to assume powersafe overwrite for modern disks.  Indeed, BerkeleyDB has
    95     95   made this assumption for decades, we are told.  Caution is advised
    96     96   though. As Roger Binns noted on the SQLite develpers mailing list:
    97     97   "'poorly written' should be the main assumption about drive firmware."
           98  +
           99  +<tcl>hd_fragment tornpage {torn page}</tcl>
          100  +<h2>Torn Pages</h2>
          101  +
          102  +<p>A torn page occurs when a database page is larger than a disk sector,
          103  +the database page is written to disk, but a power loss occurs prior to
          104  +all sectors of the database page being written.  Then, upon recovery, part of
          105  +the database page will have the old content while some other parts of the
          106  +page will have the new content.  Some database engines assume that 
          107  +page writes are atomic and hence a torn page is an unrecoverable error.
          108  +</p>
          109  +
          110  +<p>SQLite never assumes that database page writes are atomic,
          111  +regardless of the PSOW setting.<sup>(1)</sup>
          112  +And hence SQLite is always able to automatically recover from torn pages
          113  +induced by a crash.  Enabling PSOW does not decrease SQLite's ability
          114  +to recover from a torn page.</p>
    98    115   
    99    116   <h2>Changes In SQLite Version 3.7.10</h2>
   100    117   
   101    118   <p>The [VFS] for SQLite version 3.7.10 adds a new device characteristic 
   102    119   named [SQLITE_IOCAP_POWERSAFE_OVERWRITE].  Database files that report this
   103    120   characteristic are assumed to reside on storage systems that have the
   104    121   powersafe overwrite property.
   128    145      file:somefile.db?psow=0
   129    146   </blockquote>
   130    147   
   131    148   <p>There is also a new [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode for
   132    149   the [sqlite3_file_control()] that allows
   133    150   an application to query the powersafe overwrite property for a database
   134    151   file.
          152  +
          153  +<hr>
          154  +<h2>Notes:</h2>
          155  +<ol><li value=1><p>
          156  +SQLite never assumes atomic page writes <em>in its default configurations</em>.
          157  +But a custom [VFS] can sets one of the 
          158  +[SQLITE_IOCAP_ATOMIC] bits in the result of the xDeviceCharacteristic()
          159  +method and then SQLite will assume that page writes are atomic.  The
          160  +application must supply a custom VFS to accomplish this, however, since
          161  +none of the standard VFSes will ever set any of the atomic bits in the
          162  +xDeviceCharacteristics() vector.
          163  +</ol>