Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Update the mmap documentation to describe the problem of Windows not truncating memory mapped files. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
fa77748670b476dbed62f56cebf144dd |
User & Date: | drh 2014-01-30 15:56:45.740 |
Context
2014-01-30
| ||
17:41 | Fix FROM clause in the SELECT syntax diagrams. Also fix typos in the text. (check-in: a115a033da user: drh tags: trunk) | |
15:56 | Update the mmap documentation to describe the problem of Windows not truncating memory mapped files. (check-in: fa77748670 user: drh tags: trunk) | |
15:32 | Additional clarification on syntax restrictions in SELECT statements. (check-in: 4c5d78209a user: drh tags: trunk) | |
Changes
Changes to pages/mmap.in.
︙ | ︙ | |||
50 51 52 53 54 55 56 57 58 59 60 61 62 63 | is not. Not all operating systems have a unified buffer cache. In some operating systems that claim to have a unified buffer cache, the implementation is buggy and can lead to corrupt databases.</p> <li><p>Performance does not always increase with memory-mapped I/O. In fact, it is possible to construct test cases where performance is reduced by the use of memory-mapped I/O, though this is hard to do.</p> </ol> <p>Because of the potential disadvantages, memory-mapped I/O is turned off by default. To activate memory-mapped I/O, use the [mmap_size pragma] and set the mmap_size to some large number, usually 256MB or larger, depending on how much address space your application can spare. The rest is automatic. The [PRAGMA mmap_size] statement will be a silent no-op on | > > > > > > > > > > > > > | 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 | is not. Not all operating systems have a unified buffer cache. In some operating systems that claim to have a unified buffer cache, the implementation is buggy and can lead to corrupt databases.</p> <li><p>Performance does not always increase with memory-mapped I/O. In fact, it is possible to construct test cases where performance is reduced by the use of memory-mapped I/O, though this is hard to do.</p> <li><p>Windows is unable to truncate a memory-mapped file. Hence, on Windows, if an operation such as [VACUUM] or [auto_vacuum] tries to reduce the size of a memory-mapped database file, the size reduction attempt will silently fail, leaving unused space at the end of the database file. No data is lost due to this problem, and the unused space will be reused again the next time the database grows. However if a version of SQLite prior to 3.7.0 runs [PRAGMA integrity_check] on such a database, it will (incorrectly) report database corruption due to the unused space at the end. Or if a version of SQLite prior to 3.7.0 writes to the database while it still has unused space at the end, it may make that unused space inaccessible and unavailable for reuse until after the next [VACUUM]. </ol> <p>Because of the potential disadvantages, memory-mapped I/O is turned off by default. To activate memory-mapped I/O, use the [mmap_size pragma] and set the mmap_size to some large number, usually 256MB or larger, depending on how much address space your application can spare. The rest is automatic. The [PRAGMA mmap_size] statement will be a silent no-op on |
︙ | ︙ |