Documentation Source Text

Check-in [2252627a39]
Login

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

Overview
Comment:Documentation on hard-heap-limit.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 2252627a3922be14e0bcc84897b7da1bf871faa11c240395f6ac789c2ae0f059
User & Date: drh 2019-11-14 18:57:31.080
Context
2019-11-18
17:43
Mention the new SQLITE_OPEN_NOFOLLOW option in the change log. (check-in: d3ba10d894 user: drh tags: trunk)
2019-11-14
18:57
Documentation on hard-heap-limit. (check-in: 2252627a39 user: drh tags: trunk)
2019-11-07
12:48
Clarify what the file format ought to be when a WITHOUT ROWID table contains a PRIMARY KEY with redundant columns. This is not a change, but a filling in of previously omitted information. (check-in: 8cd33c0c9d user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/changes.in.
19
20
21
22
23
24
25


26
27
28
29
30
31
32
  set aChng($nChng) [list $date $desc $options]
  set xrefChng($date) $nChng
  incr nChng
}

chng {2019-12-31 (3.31.0)} {
<li>Add support for [generated columns].


<li>Faster response to [sqlite3_interrupt()].
<li>Added the [https://sqlite.org/src/file/ext/misc/uuid.c|uuid.c] extension module
    implementing functions for processing RFC-4122 UUIDs.
<li>The [legacy_file_format pragma] is deactivated.  It is now a no-op.  In its place,
    the [SQLITE_DBCONFIG_LEGACY_FILE_FORMAT] option to [sqlite3_db_config()] is
    provided.  The legacy_file_format pragma is deactivated because (1) it is
    rarely useful and (2) it is incompatible with [VACUUM] in schemas that have







>
>







19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
  set aChng($nChng) [list $date $desc $options]
  set xrefChng($date) $nChng
  incr nChng
}

chng {2019-12-31 (3.31.0)} {
<li>Add support for [generated columns].
<li>Added the [sqlite3_hard_heap_limit64()] interface and the corresponding
    [PRAGMA hard_heap_limit] command.
<li>Faster response to [sqlite3_interrupt()].
<li>Added the [https://sqlite.org/src/file/ext/misc/uuid.c|uuid.c] extension module
    implementing functions for processing RFC-4122 UUIDs.
<li>The [legacy_file_format pragma] is deactivated.  It is now a no-op.  In its place,
    the [SQLITE_DBCONFIG_LEGACY_FILE_FORMAT] option to [sqlite3_db_config()] is
    provided.  The legacy_file_format pragma is deactivated because (1) it is
    rarely useful and (2) it is incompatible with [VACUUM] in schemas that have
Changes to pages/pragma.in.
1184
1185
1186
1187
1188
1189
1190





















1191
1192
1193
1194
1195
1196
1197

    <p>^This pragma invokes the [sqlite3_soft_heap_limit64()] interface with
    the argument N, if N is specified and is a non-negative integer.
    ^The soft_heap_limit pragma always returns the same integer
    that would be returned by the [sqlite3_soft_heap_limit64](-1) C-language
    function.
    </p>





















}

Pragma synchronous {
    <p>^(<b>PRAGMA DB.synchronous;
        <br>PRAGMA DB.synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA</i><b>;</b></p>








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218

    <p>^This pragma invokes the [sqlite3_soft_heap_limit64()] interface with
    the argument N, if N is specified and is a non-negative integer.
    ^The soft_heap_limit pragma always returns the same integer
    that would be returned by the [sqlite3_soft_heap_limit64](-1) C-language
    function.
    </p>
    <p>See also the [hard_heap_limit pragma].
}

Pragma hard_heap_limit {
    <p><b>PRAGMA hard_heap_limit<br>
          PRAGMA hard_heap_limit=</b><i>N</i></p>

    <p>^This pragma invokes the [sqlite3_hard_heap_limit64()] interface with
    the argument N, if N is specified and is positive integer that
    is less than the current hard heap limit.
    ^The hard_heap_limit pragma always returns the same integer
    that would be returned by the [sqlite3_hard_heap_limit64](-1) C-language
    function.  ^That is to say, it always returns the value of the hard
    heap limit that is set after any changes imposed by this PRAGMA.
    </p>

    <p>This pragma can only lower the heap limit, never raise it.
    The C-language interface [sqlite3_hard_heap_limit64()] must be used
    to raise the heap limit.</p>

    <p>See also the [soft_heap_limit pragma].
}

Pragma synchronous {
    <p>^(<b>PRAGMA DB.synchronous;
        <br>PRAGMA DB.synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA</i><b>;</b></p>

Changes to pages/security.in.
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
from becoming a denial-of-service attack, consider using the
[sqlite3_progress_handler()] interface to invoke a callback periodically
as each SQL statement runs, and have that callback return non-zero to
abort the statement if the statement runs for too long.  Alternatively,
set a timer in a separate thread and invoke [sqlite3_interrupt()] when
the timer goes off to prevent the SQL statement from running forever.










<li><p>
In extreme cases, consider compiling SQLite with the
[-DSQLITE_ENABLE_MEMSYS5] option and then providing SQLite with
a fixed chunk of memory to use as its heap via the
[sqlite3_config]([SQLITE_CONFIG_HEAP]) interface. This will
prevent malicious SQL from executing a denial-of-service attack
by using an excessive amount of memory. If (say) 5 MB of memory
is provided for SQLite to use, once that much has been consumed,
SQLite will start returning SQLITE_NOMEM errors, rather than
soaking up memory needed by other parts of the application.
This also sandboxes SQLite's memory so that a write-after-free
error in some other part of the application will not cause
problems for SQLite, or vice versa.
</ol>

<h2>Untrusted SQLite Database Files</h2>

<p>Applications that accept untrusted database files should do the following:

<ol>
<li value="6"><p>
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
as the first SQL statement after opening the database files and
prior to running any other SQL statements.  Reject and refuse to
process any database file containing errors.

<li><p>
Enable the [PRAGMA cell_size_check=ON] setting.







>
>
>
>
>
>
>
>
>




















|







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
from becoming a denial-of-service attack, consider using the
[sqlite3_progress_handler()] interface to invoke a callback periodically
as each SQL statement runs, and have that callback return non-zero to
abort the statement if the statement runs for too long.  Alternatively,
set a timer in a separate thread and invoke [sqlite3_interrupt()] when
the timer goes off to prevent the SQL statement from running forever.

<li><p>
Limit the maximum amount of memory that SQLite will allocate using
the [sqlite3_hard_heap_limit64()] interface.  This helps prevent
denial-of-service attacks.  To find out how much heap space an
application actually needs, run the it against typical inputs and
then measure the maximum instantaneous memory usage with the 
[sqlite3_memory_highwater()] interface.  Set the hard heap limit
to the maximum observed instantaneous memory usage plus some margin.

<li><p>
In extreme cases, consider compiling SQLite with the
[-DSQLITE_ENABLE_MEMSYS5] option and then providing SQLite with
a fixed chunk of memory to use as its heap via the
[sqlite3_config]([SQLITE_CONFIG_HEAP]) interface. This will
prevent malicious SQL from executing a denial-of-service attack
by using an excessive amount of memory. If (say) 5 MB of memory
is provided for SQLite to use, once that much has been consumed,
SQLite will start returning SQLITE_NOMEM errors, rather than
soaking up memory needed by other parts of the application.
This also sandboxes SQLite's memory so that a write-after-free
error in some other part of the application will not cause
problems for SQLite, or vice versa.
</ol>

<h2>Untrusted SQLite Database Files</h2>

<p>Applications that accept untrusted database files should do the following:

<ol>
<li value="7"><p>
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
as the first SQL statement after opening the database files and
prior to running any other SQL statements.  Reject and refuse to
process any database file containing errors.

<li><p>
Enable the [PRAGMA cell_size_check=ON] setting.