Documentation Source Text

Check-in [e273b7fdae]
Login

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

Overview
Comment:Update the wal.html document at the bigwal anchor to reflect improvements to large transactions in WAL mode added to version 3.11.0.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | branch-3.11
Files: files | file ages | folders
SHA1: e273b7fdae64222f64196e80a6d4d8c2650af0be
User & Date: drh 2016-03-18 14:56:49.802
Context
2016-03-21
20:02
Fix the description of the case folding performed by the unicode61 tokenizer in FTS3. (check-in: 37a01760c6 user: drh tags: branch-3.11)
2016-03-18
15:46
Merge wal.html update from the 3.11.0 branch. (check-in: 147aa03544 user: drh tags: trunk)
14:56
Update the wal.html document at the bigwal anchor to reflect improvements to large transactions in WAL mode added to version 3.11.0. (check-in: e273b7fdae user: drh tags: branch-3.11)
2016-03-03
16:20
Add hashes to the change log. (check-in: 2fdaab5ed5 user: drh tags: branch-3.11)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/wal.in.
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
readers might block while the checkpoint is running.

<li><p>
<b>Very large write transactions.</b>
A checkpoint can only complete when no other transactions are running, 
which means the WAL file cannot be reset in the middle of a write
transaction.  So a large change to a large database
might result in a very large WAL file.  The WAL file will be checkpointed
once the write transaction completes (assuming there are no other readers
blocking it) but in the meantime, the file can grow very big.

<p>Note that sometimes the same database page can be written into
the WAL file multiple times within the same transaction, and hence the
WAL file can end up being many times larger than the original database.
This can happen when the [cache_size] is smaller then the number of
database pages changed during the transaction.
When changes are made to a page, those changes are normally held in
memory until the end of the transaction, at which point their are
written to the WAL file.  But if the cache fills up, some pages might
need to be spilled to the WAL file before the end of the transaction.
If those same pages change again, then they must be written
to the WAL file again.  For a very
large transaction and a small cache, it is possible for the same page
to spill many times and thus be written into the WAL file many times.

<p>Defenses against this failure mode include: (1) switching to a
rollback journal modes for large updates since pages are never
written into a rollback journal more than once, (2) making sure that
the [cache_size] is large enough to hold every page that will be changed
during the transaction,
(3) keeping the number of changed pages small by breaking
the transaction up into smaller chunks, and/or (4) dropping indexes before
a large insert and recreating them afterwards.
</ul>

<h2>Implementation Of Shared-Memory For The WAL-Index</h2>

<p>The [wal-index] is implemented using an ordinary file that is
mmapped for robustness.  Early (pre-release) implementations of WAL mode
stored the wal-index in volatile shared-memory, such as files created in







|



<
<
<
<
<
<
<
<
<
<
|
|
|
|
<
<
<
<
|
|
<
<







416
417
418
419
420
421
422
423
424
425
426










427
428
429
430




431
432


433
434
435
436
437
438
439
readers might block while the checkpoint is running.

<li><p>
<b>Very large write transactions.</b>
A checkpoint can only complete when no other transactions are running, 
which means the WAL file cannot be reset in the middle of a write
transaction.  So a large change to a large database
might result in a large WAL file.  The WAL file will be checkpointed
once the write transaction completes (assuming there are no other readers
blocking it) but in the meantime, the file can grow very big.











<p>As of SQLite version 3.11.0, the WAL file for a single transaction
should be proportional in size to the transaction itself.  Pages that
are changed by the transaction should only be written into the WAL file
once.  However, with older versions of SQLite, the same page might be




written into the WAL file multiple times if the transaction grows larger
than the page cache.


</ul>

<h2>Implementation Of Shared-Memory For The WAL-Index</h2>

<p>The [wal-index] is implemented using an ordinary file that is
mmapped for robustness.  Early (pre-release) implementations of WAL mode
stored the wal-index in volatile shared-memory, such as files created in