Documentation Source Text

is first detected, prior to parking the heads, as long as doing so
does not take too long, which it should not with
small and dense sectors.  Hence it seems reasonable
to assume powersafe overwrite for modern disks.  Indeed, BerkeleyDB has
made this assumption for decades, we are told.  Caution is advised
though. As Roger Binns noted on the SQLite develpers mailing list:
"'poorly written' should be the main assumption about drive firmware."

<tcl>hd_fragment tornpage {torn page}</tcl>
<h2>Torn Pages</h2>

<p>A torn page occurs when a database page is larger than a disk sector,
the database page is written to disk, but a power loss occurs prior to
all sectors of the database page being written.  Then, upon recovery, part of
the database page will have the old content while some other parts of the
page will have the new content.  Some database engines assume that 
page writes are atomic and hence a torn page is an unrecoverable error.
</p>

<p>SQLite never assumes that database page writes are atomic,
regardless of the PSOW setting.<sup>(1)</sup>
And hence SQLite is always able to automatically recover from torn pages
induced by a crash.  Enabling PSOW does not decrease SQLite's ability
to recover from a torn page.</p>

<h2>Changes In SQLite Version 3.7.10</h2>

<p>The [VFS] for SQLite version 3.7.10 adds a new device characteristic 
named [SQLITE_IOCAP_POWERSAFE_OVERWRITE].  Database files that report this
characteristic are assumed to reside on storage systems that have the
powersafe overwrite property.

   file:somefile.db?psow=0
</blockquote>

<p>There is also a new [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode for
the [sqlite3_file_control()] that allows
an application to query the powersafe overwrite property for a database
file.

<hr>
<h2>Notes:</h2>
<ol><li value=1><p>
SQLite never assumes atomic page writes <em>in its default configurations</em>.
But a custom [VFS] can sets one of the 
[SQLITE_IOCAP_ATOMIC] bits in the result of the xDeviceCharacteristic()
method and then SQLite will assume that page writes are atomic.  The
application must supply a custom VFS to accomplish this, however, since
none of the standard VFSes will ever set any of the atomic bits in the
xDeviceCharacteristics() vector.
</ol>