Documentation Source Text

Check-in [e97f045354]
Login

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

Overview
Comment:Fix a typo on the wal.html page.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: e97f04535496696553bdbc2d3a11f30d69225e20
User & Date: drh 2016-05-26 17:57:06.689
Context
2016-06-01
11:18
Fix typo in the description of the blessing. (check-in: 8ff18d7976 user: drh tags: trunk)
2016-05-26
17:57
Fix a typo on the wal.html page. (check-in: e97f045354 user: drh tags: trunk)
2016-05-23
18:10
Fix typo. (check-in: a88d4c2239 user: mistachkin tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/wal.in.
︙︙
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155

readers, writers and readers can run at the same time.  However,
since there is only one WAL file, there can only be one writer at
a time.</p>

<p>A checkpoint operation takes content from the WAL file
and transfers it back into the original database file.
A checkpoint can run concurrently with readers, however the checkpoint
must stop when it reaches a page in the WAL that is past the read mark
of any current reader.  The checkpoint has to stop at that point because
otherwise it might overwrite part of the database file that the reader
is actively using.  The checkpoint remembers (in the wal-index) how far
it got and will resume transferring content from the WAL to the database
from where it left off on the next invocation.</p>

<p>Thus a long-running read transaction can prevent a checkpointer from








|








141
142
143
144
145
146
147
148
149
150
151
152
153
154
155

readers, writers and readers can run at the same time.  However,
since there is only one WAL file, there can only be one writer at
a time.</p>

<p>A checkpoint operation takes content from the WAL file
and transfers it back into the original database file.
A checkpoint can run concurrently with readers, however the checkpoint
must stop when it reaches a page in the WAL that is past the end mark
of any current reader.  The checkpoint has to stop at that point because
otherwise it might overwrite part of the database file that the reader
is actively using.  The checkpoint remembers (in the wal-index) how far
it got and will resume transferring content from the WAL to the database
from where it left off on the next invocation.</p>

<p>Thus a long-running read transaction can prevent a checkpointer from
︙︙