Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Import the SQLite core library docs from upstream that correspond to version 3.12.0. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
94e181cde011a74ad8597d67ad93791c |
User & Date: | mistachkin 2016-03-29 20:40:56.203 |
Context
2016-03-30
| ||
21:02 | Update the MSVCRT runtimes for VS 2015 in externals to 'Update 2', part 1. check-in: f586f38b68 user: mistachkin tags: trunk | |
2016-03-29
| ||
20:40 | Import the SQLite core library docs from upstream that correspond to version 3.12.0. check-in: 94e181cde0 user: mistachkin tags: trunk | |
18:10 | Update SQLite core library to the 3.12.0 release. check-in: 6b199ba3e1 user: mistachkin tags: trunk | |
Changes
Changes to Doc/Extra/Core/pragma.html.
︙ | ︙ | |||
405 406 407 408 409 410 411 | that SQLite will hold in memory at once per open database file. Whether or not this suggestion is honored is at the discretion of the <a href="c3ref/pcache_methods2.html">Application Defined Page Cache</a>. The default page cache that is built into SQLite honors the request, however alternative application-defined page cache implementations may choose to interpret the suggested cache size in different ways or to ignore it all together. | | > | 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 | that SQLite will hold in memory at once per open database file. Whether or not this suggestion is honored is at the discretion of the <a href="c3ref/pcache_methods2.html">Application Defined Page Cache</a>. The default page cache that is built into SQLite honors the request, however alternative application-defined page cache implementations may choose to interpret the suggested cache size in different ways or to ignore it all together. The default suggested cache size is -2000, which means the cache size is limited to 2048000 bytes of memory. The default suggested cache size can be altered using the <a href="compile.html#default_cache_size">SQLITE_DEFAULT_CACHE_SIZE</a> compile-time options. The TEMP database has a default suggested cache size of 0 pages.</p> <p>If the argument N is positive then the suggested cache size is set to N. If the argument N is negative, then the number of cache pages is adjusted to use approximately abs(N*1024) bytes |
︙ | ︙ | |||
1145 1146 1147 1148 1149 1150 1151 | <hr> <p><b>PRAGMA </b><i>schema.</i><b>page_size; <br>PRAGMA </b><i>schema.</i><b>page_size = </b><i>bytes</i><b>;</b></p> <p>Query or set the page size of the database. The page size must be a power of two between 512 and 65536 inclusive. </p> | | | > | > | | < < < < < < < < | < < < < < < < < < < < | < | 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 | <hr> <p><b>PRAGMA </b><i>schema.</i><b>page_size; <br>PRAGMA </b><i>schema.</i><b>page_size = </b><i>bytes</i><b>;</b></p> <p>Query or set the page size of the database. The page size must be a power of two between 512 and 65536 inclusive. </p> <p>When a new database is created, SQLite assigned a page size to the database based on platform and filesystem. For many years, the default page size was almost always 1024 bytes, but beginning with SQLite <a href="releaselog/3_12_0.html">version 3.12.0</a> in 2016, the default page size increased to 4096. <p>The page_size pragma will only cause an immediate change in the page size if it is issued while the database is still empty, prior to the first CREATE TABLE statement. If the page_size pragma is used to specify a new page size just prior to running the <a href="lang_vacuum.html">VACUUM</a> command and if the database is not in <a href="wal.html">WAL journal mode</a> then <a href="lang_vacuum.html">VACUUM</a> will change the page size to the new value.</p> <p>The <a href="compile.html#default_page_size">SQLITE_DEFAULT_PAGE_SIZE</a> compile-time option can be used to change the default page size assigned to new databases. <a name="pragma_parser_trace"></a> <hr> <p><b>PRAGMA parser_trace = </b><i>boolean</i><b>; </b></p> <p>If SQLite has been compiled with the <a href="compile.html#debug">SQLITE_DEBUG</a> compile-time option, then the parser_trace pragma can be used to turn on tracing for the SQL parser used internally by SQLite. |
︙ | ︙ | |||
1399 1400 1401 1402 1403 1404 1405 | <dd> When synchronous is FULL (2), the SQLite database engine will use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely written to the disk surface prior to continuing. This ensures that an operating system crash or power failure will not corrupt the database. FULL synchronous is very safe, but it is also slower. FULL is the | | | | 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 | <dd> When synchronous is FULL (2), the SQLite database engine will use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely written to the disk surface prior to continuing. This ensures that an operating system crash or power failure will not corrupt the database. FULL synchronous is very safe, but it is also slower. FULL is the most commonly used synchronous setting when not in <a href="wal.html">WAL mode</a>.</dd> <dt><b>NORMAL</b> (1)</dt> <dd> When synchronous is NORMAL (1), the SQLite database engine will still sync at the most critical moments, but less often than in FULL mode. There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode. But in practice, you are more likely to suffer a catastrophic disk failure or some other unrecoverable hardware fault. Many applications choose NORMAL when in <a href="wal.html">WAL mode</a>.</dd> <dt><b>OFF</b> (0)</dt> <dd> With synchronous OFF (0), SQLite continues without syncing as soon as it has handed data off to the operating system. If the application running SQLite crashes, the data will be safe, but the database might become corrupted if the operating system crashes or the computer loses power before that data has been written |
︙ | ︙ | |||
1434 1435 1436 1437 1438 1439 1440 | sync operation of the WAL file happens after each transaction commit. The extra WAL sync following each transaction help ensure that transactions are durable across a power loss, but they do not aid in preserving consistency. If durability is not a concern, then synchronous=NORMAL is normally all one needs in WAL mode.</p> | | < | 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 | sync operation of the WAL file happens after each transaction commit. The extra WAL sync following each transaction help ensure that transactions are durable across a power loss, but they do not aid in preserving consistency. If durability is not a concern, then synchronous=NORMAL is normally all one needs in WAL mode.</p> <p>The default setting is usually synchronous=FULL. The <a href="compile.html#extra_durable">SQLITE_EXTRA_DURABLE</a> compile-time option changes the default to synchronous=EXTRA.</p> <p>See also the <a href="pragma.html#pragma_fullfsync">fullfsync</a> and <a href="pragma.html#pragma_checkpoint_fullfsync">checkpoint_fullfsync</a> pragmas.</p> <a name="pragma_table_info"></a> <hr> <p><b>PRAGMA </b><i>schema.</i><b>table_info(</b><i>table-name</i><b>);</b></p> |
︙ | ︙ |