Documentation Source Text

Check-in [1a4aa7fa1d]
Login

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

Overview
Comment:Fix typo reported by Jeffrey Mattox.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | 3.17
Files: files | file ages | folders
SHA1: 1a4aa7fa1d4bbed9bef9d9b89505cea8af6d0316
User & Date: drh 2017-03-04 20:09:15.281
Context
2017-03-06
11:34
Fix typos in the malloc.html document. (check-in: 31b59e00e5 user: drh tags: 3.17)
2017-03-04
20:09
Fix typo reported by Jeffrey Mattox. (check-in: 1a4aa7fa1d user: drh tags: 3.17)
2017-02-22
12:43
Fix typos in the documentation reported by Karol Swietlicki. (check-in: d24b5395d0 user: drh tags: 3.17)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/wal.in.
︙︙
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167

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
making progress.  But presumably every read transactions will eventually
end and the checkpointer will be able to continue.</p>

<p>Whenever a write operation occurs, the writer checks how much progress
the checkpointer has made, and if the entire WAL has been transferred into
the database and synced and if no readers are making use of the WAL, then
the writer will rewind the WAL back to the beginning and start putting new
transactions at the beginning of the WAL.  This mechanism prevents a WAL








|








153
154
155
156
157
158
159
160
161
162
163
164
165
166
167

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
making progress.  But presumably every read transaction will eventually
end and the checkpointer will be able to continue.</p>

<p>Whenever a write operation occurs, the writer checks how much progress
the checkpointer has made, and if the entire WAL has been transferred into
the database and synced and if no readers are making use of the WAL, then
the writer will rewind the WAL back to the beginning and start putting new
transactions at the beginning of the WAL.  This mechanism prevents a WAL
︙︙