Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Fix typo reported by Jeffrey Mattox. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | 3.17 |
| Files: | files | file ages | folders |
| SHA1: |
1a4aa7fa1d4bbed9bef9d9b89505cea8 |
| User & Date: | drh 2017-03-04 20:09:15 |
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
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 |