Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Updates to the atomic commit document in order to reference WAL and PSOW and to improve clarity of presentation. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
aaf3ea1155e0acc24b20ad0dc1da13b7 |
User & Date: | drh 2012-04-02 15:49:34.434 |
Context
2012-04-03
| ||
02:04 | Documentation on how to configure R*Tree for integer-only operation. (check-in: 7404688990 user: drh tags: trunk) | |
2012-04-02
| ||
15:49 | Updates to the atomic commit document in order to reference WAL and PSOW and to improve clarity of presentation. (check-in: aaf3ea1155 user: drh tags: trunk) | |
15:00 | Enforce the 80-character line limit on the new documentation source text for FTS4 commands. (check-in: f1d54965d0 user: drh tags: trunk) | |
Changes
Changes to pages/atomiccommit.in.
︙ | ︙ | |||
24 25 26 27 28 29 30 | <p>SQLite has the important property that transactions appear to be atomic even if the transaction is interrupted by an operating system crash or power failure.</p> <p>This article describes the techniques used by SQLite to create the illusion of atomic commit.</p> | | > | | > > > | 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | <p>SQLite has the important property that transactions appear to be atomic even if the transaction is interrupted by an operating system crash or power failure.</p> <p>This article describes the techniques used by SQLite to create the illusion of atomic commit.</p> <p>The information in this article applies only when SQLite is operating in "rollback mode", or in other words when SQLite is not using a [write-ahead log]. SQLite still supports atomic commit when write-ahead logging is enabled, but it accomplishes atomic commit by a different mechanism from the one describe in this article. See the [WAL | write-ahead log documentation] for additional information on how SQLite supports atomic commit in that context.</p> <tcl>hd_fragment hardware</tcl> <h2>2.0 Hardware Assumptions</h2> <p>Throughout this article, we will call the mass storage device "disk" even though the mass storage device might really be flash memory.</p> |
︙ | ︙ | |||
66 67 68 69 70 71 72 | method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device manufactures to tweak according to their own needs. And we have left open the possibility of filling in a more meaningful implementation on Unix and Windows in the future.</p> | | | | 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device manufactures to tweak according to their own needs. And we have left open the possibility of filling in a more meaningful implementation on Unix and Windows in the future.</p> <p>SQLite has traditionally assumed that a sector write is <u>not</u> atomic. However, SQLite does always assume that a sector write is linear. By "linear" we mean that SQLite assumes that when writing a sector, the hardware begins at one end of the data and writes byte by byte until it gets to the other end. The write might go from beginning to end or from end to beginning. If a power failure occurs in the middle of a sector write it might be that part of the sector was modified and another part was left unchanged. The key assumption by SQLite is that if any part of the sector gets changed, then either the |
︙ | ︙ | |||
151 152 153 154 155 156 157 158 159 160 161 162 163 164 | bit errors caused by cosmic rays, thermal noise, quantum fluctuations, device driver bugs, or other mechanisms, is the responsibility of the underlying hardware and operating system. SQLite does not add any redundancy to the database file for the purpose of detecting corruption or I/O errors. SQLite assumes that the data it reads is exactly the same data that it previously wrote.</p> <a name="section_3_0"></a> <h2>3.0 Single File Commit</h2> <p>We begin with an overview of the steps SQLite takes in order to perform an atomic commit of a transaction against a single database file. The details of file formats used to guard against damage from | > > > > > > > > > > > > > > | 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 | bit errors caused by cosmic rays, thermal noise, quantum fluctuations, device driver bugs, or other mechanisms, is the responsibility of the underlying hardware and operating system. SQLite does not add any redundancy to the database file for the purpose of detecting corruption or I/O errors. SQLite assumes that the data it reads is exactly the same data that it previously wrote.</p> <p>By default, SQLite assumes that an operating system call to write a range of bytes will not damage or alter any bytes outside of that range even if a power lose or OS crash occurs during that write. We call this the "[PSOW | powersafe overwrite]" property. Prior to version 3.7.9, SQLite did not assume powersafe overwrite. But with the standard sector size increasing from 512 to 4096 bytes on most disk drives, it has become necessary to assume powersafe overwrite in order to maintain historical performance levels and so powersafe overwrite is assumed by default in recent versions of SQLite. The assumption of powersafe overwrite property can be disabled at compile-time or a run-time if desired. See the [PSOW | powersafe overwrite documentation] for further details. <a name="section_3_0"></a> <h2>3.0 Single File Commit</h2> <p>We begin with an overview of the steps SQLite takes in order to perform an atomic commit of a transaction against a single database file. The details of file formats used to guard against damage from |
︙ | ︙ |