Documentation Source Text

Changes On Branch branch-3.14
Login
Home Timeline Branches Tickets Wiki More...
Hide Diff Patch Unified Diff

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

Changes In Branch branch-3.14 Excluding Merge-Ins

This is equivalent to a diff from 54fe7773db to aa3809f595

2016-09-21
04:21
Remove duplicate disadvantage to WAL mode. (Leaf check-in: aa3809f595 user: drh tags: branch-3.14)
04:17
Remove duplicate disadvantage to WAL mode. (check-in: 4e5ba5873c user: drh tags: trunk)
2016-09-17
15:49
Provide a link to the draft changelog on the prerelease snapshot description. (check-in: 90de403f24 user: drh tags: branch-3.14)
2016-09-14
04:12
Start a change log for 3.15.0. Begin writing documentation for row values and for the generate_series table-valued function. (check-in: bdbea7dc63 user: drh tags: trunk)
03:45
Add the 3.14.2 release to the chronology. (check-in: 54fe7773db user: drh tags: trunk)
03:39
Add the correct release date for 3.14.2 on the homepage. (check-in: b7faa9d562 user: drh tags: trunk)

Changes to pages/download.in.

︙︙
100
101
102
103
104
105
106

107
108
109
110
111
112
113


Heading {Pre-release Snapshots} {} $Caution


Product {snapshot/sqlite-snapshot-DATE.tar.gz} {
  The [amalgamation] source code, the [command-line shell] source code,
  configure/make scripts for unix, and a Makefile.msc for Windows.

}
Product {snapshot/sqlite-amalgamation-DATE.zip} {
  The [amalgamation]: complete source code a single "sqlite3.c" file.
}
#  The [amalgamation] as of VERSION.
#  See the <a href="http://www.sqlite.org/draft/releaselog/current.html">pending
#  change log</a> for details.








>








100
101
102
103
104
105
106
107
108
109
110
111
112
113
114


Heading {Pre-release Snapshots} {} $Caution


Product {snapshot/sqlite-snapshot-DATE.tar.gz} {
  The [amalgamation] source code, the [command-line shell] source code,
  configure/make scripts for unix, and a Makefile.msc for Windows.
  [https://www.sqlite.org/draft/releaselog/current.html|Change log].
}
Product {snapshot/sqlite-amalgamation-DATE.zip} {
  The [amalgamation]: complete source code a single "sqlite3.c" file.
}
#  The [amalgamation] as of VERSION.
#  See the <a href="http://www.sqlite.org/draft/releaselog/current.html">pending
#  change log</a> for details.
︙︙

Changes to pages/wal.in.

︙︙
34
35
36
37
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

    support this but third-party extension VFSes for custom operating
    systems might not.
<li>All processes using a database must be on the same host computer;
    WAL does not work over a network filesystem.
<li>Transactions that involve changes against multiple [ATTACH | ATTACHed]
    databases are atomic for each individual database, but are not
    atomic across all databases as a set.
<li>It is not possible to change the database page size after entering WAL
    mode, either on an empty database or by using [VACUUM] or by restoring
    from a backup using the [backup API].  You must be in a rollback journal
    mode to change the page size.
<li>It is not possible to open [read-only WAL databases].
    The opening process must have write privileges for "<tt>-shm</tt>"
    [wal-index] shared memory file associated with the database, if that
    file exists, or else write access on the directory containing
    the database file if the "<tt>-shm</tt>" file does not exist.
<li>WAL might be very slightly slower (perhaps 1% or 2% slower)
    than the traditional rollback-journal approach
    in applications that do mostly reads and seldom write.
<li>There is an additional quasi-persistent "<tt>-wal</tt>" file and
    "<tt>-shm</tt>" shared memory file associated with each
    database, which can make SQLite less appealing for use as an 
    [application file-format].
<li>There is the extra operation of [checkpointing] which, though automatic
    by default, is still something that application developers need to
    be mindful of.
<li>The [page_size] of the database file cannot be changed while in WAL mode.
<li><s>WAL works best with smaller transactions.  WAL does
    not work well for very large transactions.  For transactions larger than
    about 100 megabytes, traditional rollback journal modes will likely
    be faster.  For transactions in excess of a gigabyte, WAL mode may 
    fail with an I/O or disk-full error.
    It is recommended that one of the rollback journal modes be used for
    transactions larger than a few dozen megabytes.</s>








|


















<








34
35
36
37
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

    support this but third-party extension VFSes for custom operating
    systems might not.
<li>All processes using a database must be on the same host computer;
    WAL does not work over a network filesystem.
<li>Transactions that involve changes against multiple [ATTACH | ATTACHed]
    databases are atomic for each individual database, but are not
    atomic across all databases as a set.
<li>It is not possible to change the [page_size] after entering WAL
    mode, either on an empty database or by using [VACUUM] or by restoring
    from a backup using the [backup API].  You must be in a rollback journal
    mode to change the page size.
<li>It is not possible to open [read-only WAL databases].
    The opening process must have write privileges for "<tt>-shm</tt>"
    [wal-index] shared memory file associated with the database, if that
    file exists, or else write access on the directory containing
    the database file if the "<tt>-shm</tt>" file does not exist.
<li>WAL might be very slightly slower (perhaps 1% or 2% slower)
    than the traditional rollback-journal approach
    in applications that do mostly reads and seldom write.
<li>There is an additional quasi-persistent "<tt>-wal</tt>" file and
    "<tt>-shm</tt>" shared memory file associated with each
    database, which can make SQLite less appealing for use as an 
    [application file-format].
<li>There is the extra operation of [checkpointing] which, though automatic
    by default, is still something that application developers need to
    be mindful of.

<li><s>WAL works best with smaller transactions.  WAL does
    not work well for very large transactions.  For transactions larger than
    about 100 megabytes, traditional rollback journal modes will likely
    be faster.  For transactions in excess of a gigabyte, WAL mode may 
    fail with an I/O or disk-full error.
    It is recommended that one of the rollback journal modes be used for
    transactions larger than a few dozen megabytes.</s>
︙︙

This page was generated in about 0.036s by Fossil 2.24 [71919ad1b5] 2024-04-17 13:27:34