Documentation Source Text

Check-in [4f85463d41]
Login

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

Overview
Comment:Clarification of the checkpoint algorithm in the file format document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 4f85463d41431a2ac61b333686e909d77d0d4edf
User & Date: drh 2015-11-11 00:22:10
Context
2015-11-11
20:52
Fix a typo in the virtual table documentation. check-in: 04edad8b2f user: drh tags: trunk
00:22
Clarification of the checkpoint algorithm in the file format document. check-in: 4f85463d41 user: drh tags: trunk
2015-11-09
21:21
Clarification of rules regarding SQLITE_OMIT_ compile-time options. Other minor documentation fixes. check-in: ff45f132a6 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/fileformat2.in.

1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764


1765
1766
1767
1768
1769
1770
1771
^Then valid content of the WAL is transferred into the database file.
^Finally, the database is flushed to persistent storage using another
xSync method call.
The xSync operations serve as write barriers - all writes launched
before the xSync must complete before any write that launches after the
xSync begins.</p>

<p>^After each checkpoint, the WAL header salt-1 value is incremented and the 
salt-2 value is randomized.  This prevents old and new frames in the WAL from
being considered valid at the same time and being checkpointing together
following a crash.</p>



<tcl>hd_fragment walread {WAL read algorithm}</tcl>
<h3>4.4 Reader Algorithm</h3>

<p>^(To read a page from the database (call it page number P), a reader
first checks the WAL to see if it contains page P.  If so, then the
last valid instance of page P that is followed by a commit frame







|
|
|
|
>
>







1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
^Then valid content of the WAL is transferred into the database file.
^Finally, the database is flushed to persistent storage using another
xSync method call.
The xSync operations serve as write barriers - all writes launched
before the xSync must complete before any write that launches after the
xSync begins.</p>

<p>^After a checkpoint, new write transactions overwrite
the WAL file from the beginning.  ^At the start of the first new
write transaction, the WAL header salt-1 value is incremented
and the salt-2 value is randomized.  These changes to the salts invalidate
old frames in the WAL that have already been checkpointed but not yet
overwritten, and prevent them from being checkpointed again.</p>

<tcl>hd_fragment walread {WAL read algorithm}</tcl>
<h3>4.4 Reader Algorithm</h3>

<p>^(To read a page from the database (call it page number P), a reader
first checks the WAL to see if it contains page P.  If so, then the
last valid instance of page P that is followed by a commit frame