Documentation Source Text

Check-in [9f03d7ca10]
Login

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

Overview
Comment:Fix a minor formatting issue in the tempfiles.html document.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 9f03d7ca1051a17a7c805fadb56f5e2f14f8e76f90a246b488ab5731e52247c7
User & Date: drh 2018-04-13 15:09:00.874
Context
2018-04-14
10:22
Minor edits to whynotgit.html due to Reddit comments. (check-in: 2ad4610bdf user: drh tags: trunk)
2018-04-13
15:09
Fix a minor formatting issue in the tempfiles.html document. (check-in: 9f03d7ca10 user: drh tags: trunk)
2018-04-12
18:21
More tweaks to the whynotgit.html document. (check-in: 200882d3ff user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/tempfiles.in.
︙︙
228
229
230
231
232
233
234
235
236
237
238

239
240
241
242
243


244
245
246
247
248
249
250

would not be atomic across all databases.  In other words, if the
commit were interrupted in the middle by a crash or power loss, then
the changes to one of the databases might complete while the changes
to another database might roll back.  The master journal causes all
changes in all databases to either rollback or commit together.
</p>

</p>
The master journal file is only created for [COMMIT] operations that
involve multiple database files where at least two of the databases 
meet all of the following requirements:

<ol>
<li>The database is modified by the transaction
<li>The [PRAGMA synchronous] setting is not OFF
<li>The [PRAGMA journal_mode] is not OFF, MEMORY, or WAL
</ol>


This means that SQLite transactions are not atomic
across multiple database files on a power-loss when the database 
files have synchronous turned off or when they are using journal 
modes of OFF, MEMORY, or WAL.  For synchronous OFF and for
journal_modes OFF and MEMORY, database will usually corrupt if
a transaction commit is interrupted by a power loss.  For 
[WAL mode], individual database files are updated atomically








|



>





>
>








228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253

would not be atomic across all databases.  In other words, if the
commit were interrupted in the middle by a crash or power loss, then
the changes to one of the databases might complete while the changes
to another database might roll back.  The master journal causes all
changes in all databases to either rollback or commit together.
</p>

<p>
The master journal file is only created for [COMMIT] operations that
involve multiple database files where at least two of the databases 
meet all of the following requirements:

<ol>
<li>The database is modified by the transaction
<li>The [PRAGMA synchronous] setting is not OFF
<li>The [PRAGMA journal_mode] is not OFF, MEMORY, or WAL
</ol>

<p>
This means that SQLite transactions are not atomic
across multiple database files on a power-loss when the database 
files have synchronous turned off or when they are using journal 
modes of OFF, MEMORY, or WAL.  For synchronous OFF and for
journal_modes OFF and MEMORY, database will usually corrupt if
a transaction commit is interrupted by a power loss.  For 
[WAL mode], individual database files are updated atomically
︙︙