Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Edits to the VFS documentation. Better cross-referencing to VFS. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
e63c0ce4fb1d824ffcac9360ecc6f24c |
User & Date: | drh 2011-05-23 19:04:56.407 |
Context
2011-05-24
| ||
00:44 | Restrict website search text to omit non-alphanumeric characters. (check-in: 2528553d5a user: drh tags: trunk) | |
2011-05-23
| ||
19:04 | Edits to the VFS documentation. Better cross-referencing to VFS. (check-in: e63c0ce4fb user: drh tags: trunk) | |
2011-05-20
| ||
23:21 | Further tightening of the validity rules for valid HTTP requests in althttpd.c. (check-in: 73bc374298 user: drh tags: trunk) | |
Changes
Changes to pages/atomiccommit.in.
︙ | |||
83 84 85 86 87 88 89 | 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 | - + | never start writing a sector in the middle and work towards the ends. We do not know if this assumption is always true but it seems reasonable.</p> <p>The previous paragraph states that SQLite does not assume that sector writes are atomic. This is true by default. But as of SQLite version 3.5.0, there is a new interface called the |
︙ | |||
122 123 124 125 126 127 128 | 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 | - + | file space originally contains garbage and then later is filled in with the data actually written. In other words, SQLite assumes that the file size is updated before the file content. This is a pessimistic assumption and SQLite has to do some extra work to make sure that it does not cause database corruption if power is lost between the time when the file size is increased and when the new content is written. The xDeviceCharacteristics method of |
︙ |
Changes to pages/compile.in.
︙ | |||
371 372 373 374 375 376 377 | 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 | - + - + | <li> No locking style. If none of the above can be supported, this locking style is used. No database locking mechanism is used. When this system is used it is not safe for a single database to be accessed by multiple clients. </ul> |
︙ |
Changes to pages/fileformat2.in.
︙ | |||
360 361 362 363 364 365 366 | 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 | - + - + - + | that contains the bytes at offsets between 1073741824 and 1073742335, inclusive. A database file that is less than or equal to 1073741824 bytes in size contains no lock-byte page. A database file larger than 1073741824 contains exactly one lock-byte page. </p> <p>The lock-byte page is set aside for use by the operating-system specific |
︙ |
Changes to pages/pragma.in.
︙ | |||
743 744 745 746 747 748 749 | 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 | - + | <p>^(<b>PRAGMA synchronous; <br>PRAGMA synchronous = </b> <i>0 | OFF | 1 | NORMAL | 2 | FULL</i><b>;</b></p> <p>Query or change the setting of the "synchronous" flag.)^ ^The first (query) form will return the synchronous setting as an integer. ^When synchronous is FULL (2), the SQLite database engine will |
︙ |
Changes to pages/selfcontained.in.
︙ | |||
33 34 35 36 37 38 39 | 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | - + - | The date and time SQL functions provided by SQLite require some additional C library support, but those functions can be also be omitted from the build using compile-time options. </p> <p> Communications between SQLite and the operating system and disk are |
︙ |
Changes to pages/testing.in.
︙ | |||
296 297 298 299 300 301 302 | 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 | - + - + | course, and so crash testing is done in simulation. An alternative [sqlite3_vfs | Virtual File System] is inserted that allows the test harness to simulate the state of the database file following a crash.</p> <p>In the TCL test harness, the crash simulation is done in a separate process. The main testing process spawns a child process which runs some SQLite operation and randomly crashes somewhere in the middle of |
︙ | |||
420 421 422 423 424 425 426 | 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 | - + | <p>The SQLite core has 100% branch test coverage under [TH3] as of 2009-07-25, in its default configuration as measured by [http://gcc.gnu.org/onlinedocs/gcc/Gcov.html | gcov] utility on SuSE Linux 10.1 on x86 hardware with the GCC 4.0.1 compiler.</p> <p>The "SQLite core" in the previous paragraph excludes the |
︙ | |||
708 709 710 711 712 713 714 | 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 | - + | <tcl>hd_fragment journaltest</tcl> <h3>8.5 Journal Tests</h3> <p>One of the things that SQLite does to ensure that transactions are atomic across system crashes and power failures is to write all changes into the rollback journal file prior to changing the database. The TCL test harness contains an alternative |
︙ |
Changes to pages/th3.in.
︙ | |||
23 24 25 26 27 28 29 | 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | - + | errors, and power loss during transaction commit. </p></li> <li><p> TH3 exercises SQLite in a variety of run-time configurations (UTF8 vs UTF16, different pages sizes, varying journal modes, etc.) </p></li> <li><p> TH3 achieves 100% branch test coverage over SQLite core. |
︙ |
Changes to pages/vfs.in.
1 2 3 4 5 6 7 8 9 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | - - + + - - + + | <title>The OS Backend (VFS) To SQLite</title> <tcl>hd_keywords VFS VFSes {OS backend}</tcl> <h1 align="center"> The SQLite OS Interface or "VFS" </h1> <p> This article describes the SQLite OS portability layer or "VFS" - the |
︙ | |||
38 39 40 41 42 43 44 | 38 39 40 41 42 43 44 45 46 47 48 49 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 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 | - - - + + + + - + - + - - - - - + + + + + + - + + + - - + + | <p> This article is about the bottom layer. </p> <p>The OS Interface - also called the "VFS" - is what makes SQLite portable across operating systems. Whenever any of the other modules |
︙ | |||
145 146 147 148 149 150 151 | 149 150 151 152 153 154 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 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 | - - - + + + + - - + + - + - + - + - + - + - + | a VFS specified as the fourth argument to [sqlite3_open_v2()]. The default VFS is used if no VFS is specified otherwise. </p> <h2>2.2 VFS Shims</h2> <p> |
︙ |
Changes to pages/wal.in.
︙ | |||
20 21 22 23 24 25 26 | 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | - - + + | <li>WAL uses many fewer fsync() operations and is thus less vulnerable to problems on systems where the fsync() system call is broken. </ol> <p>But there are also disadvantages:</p> <ol> |
︙ | |||
243 244 245 246 247 248 249 | 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 | - + | <blockquote><pre> PRAGMA journal_mode=WAL; </pre></blockquote> <p>The journal_mode pragma returns a string which is the new journal mode. On success, the pragma will return the string "<tt>wal</tt>". If |
︙ | |||
309 310 311 312 313 314 315 | 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 | - + | operations.</p> <p>An efficient implementation of the [WAL read algorithm] requires that there exist a hash table in shared memory over the content of the WAL file. This hash table is called the [wal-index]. The wal-index is in shared memory, and so technically it does not have to have a name in the host computer filesystem. Custom |
︙ | |||
361 362 363 364 365 366 367 | 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 | - + - + | think this is a major concern since the wal-index rarely exceeds 32 KiB in size and is never synced. Furthermore, the wal-index backing file is deleted when the last database connection disconnects, which often prevents any real disk I/O from ever happening.</p> <p>Specialized applications for which the default implementation of shared memory is unacceptable can devise alternative methods via a |
︙ |