HLR H30010
The system shall ensure that at the successful conclusion of a
database transaction the contents of the database file constitute
a well-formed SQLite database file.
HLR H30020
The system shall ensure that at the successful conclusion of a
database transaction the contents of the database file are a valid
serialization of the contents of the logical SQL database produced
by the transaction.
HLR H30030
The first 16 bytes of a well-formed database file shall contain
the UTF-8 encoding of the string "SQLite format 3" followed by a
single nul-terminator byte.
HLR H30040
The 6 bytes beginning at byte offset 18 of a well-formed database
image shall contain the values 0x01, 0x01, 0x00, 0x40, 0x20 and
0x20, respectively.
HLR H30120
The 4-byte big-endian signed integer field at byte offset 44 of a
well-formed database image, the schema layer file format field,
shall be set to an integer value between 1 and 4, inclusive.
HLR H30130
The 4-byte big-endian unsigned integer field at byte offset 48 of a
well-formed database image shall be set to the value of the
database default page-cache size.
HLR H30140
If the database is not an auto-vacuum capable database, then the 4 byte
big-endian unsigned integer field at byte offset 52 of a well-formed
database image shall contain the value 0.
HLR H30141
If the database is an auto-vacuum capable database, then the 4 byte
big-endian unsigned integer field at byte offset 52 of a well-formed
database image shall contain the numerically largest root-page number
of any table or index B-Tree within the database image.
HLR H30150
The 4 byte big-endian unsigned integer field at byte offset 56 of a
well-formed database image shall be set to 1 if the database text-encoding
is UTF-8, 2 if the database text-encoding is little-endian UTF-16, and 3
if the database text-encoding is big-endian UTF-16.
HLR H30160
The 4-byte big-endian unsigned integer field at byte offset 60 of a
well-formed database image shall be set to the value of the
database user-cookie.
HLR H30190
The 2-byte big-endian unsigned integer field at byte offset 16 of a
well-formed database image shall be set to the value of the database
page-size.
HLR H30191
The page-size of an SQLite database in bytes shall be an integer power
of 2 between 512 and 32768, inclusive.
HLR H30170
The 4-byte big-endian unsigned integer field at byte offset 64 of a
well-formed database image shall be set to the value of the database
incremental-vacuum flag.
HLR H30171
The value of the incremental-vacuum flag of an SQLite database shall be
either 0 or 1.
HLR H30180
In a well-formed non-autovacuum database (one with a zero stored
in the 4-byte big-endian integer value beginning at byte offset
52 of the database file header, the incremental vacuum flag is
set to 0.
HLR H30200
The size of a well formed database image shall be an integer
multiple of the database page size.
HLR H30210
Each page of a well formed database image shall be exactly one of a
B-Tree page, an overflow page, a free page, a
pointer-map page or the locking page.
HLR H30220
The database page that starts at byte offset 230, the
locking page, shall never be used for any purpose.
HLR H30230
In a well-formed database file, the portion of the first
database page not consumed by the database file-header (all but the
first 100 bytes) contains the root node of a table B-Tree,
the schema table.
HLR H30240
All records stored in the schema table contain exactly five
fields.
HLR H30250
For each SQL table in the database apart from itself
("sqlite_master"), the schema table of a well-formed
database file contains an associated record.
HLR H30260
The first field of each schema table record associated with an
SQL table shall be the text value "table".
HLR H30270
The second field of each schema table record associated with an
SQL table shall be a text value set to the name of the SQL table.
HLR H30280
In a well-formed database file, the third field of all
schema table records associated with SQL tables shall contain
the same value as the second field.
HLR H30290
In a well-formed database file, the fourth field of all
schema table records associated with SQL tables that are not
virtual tables contains the page number (an integer value) of the root
page of the associated table B-Tree structure within the
database file.
HLR H30300
If the associated database table is a virtual table, the fourth
field of the schema table record shall contain the integer
value 0 (zero).
HLR H30310
In a well-formed database, the fifth field of all schema table
records associated with SQL tables shall contain a "CREATE TABLE"
or "CREATE VIRTUAL TABLE" statement (a text value). The details
of the statement shall be such that executing the statement
would create a table of precisely the same name and schema as the
existing database table.
HLR H30320
For each PRIMARY KEY or UNIQUE constraint present in the definition
of each SQL table in the database, the schema table of a well-formed
database shall contain a record with the first field set to the text
value "index", and the second field set to a text value containing a
string of the form "sqlite_autoindex_<name>_<idx>", where
<name> is the name of the SQL table and <idx> is an
integer value.
HLR H30330
In a well-formed database, the third field of all schema table
records associated with SQL PRIMARY KEY or UNIQUE constraints shall
contain the name of the table to which the constraint applies (a
text value).
HLR H30340
In a well-formed database, the fourth field of all schema table
records associated with SQL PRIMARY KEY or UNIQUE constraints shall
contain the page number (an integer value) of the root page of the
associated index B-Tree structure.
HLR H30350
In a well-formed database, the fifth field of all schema table
records associated with SQL PRIMARY KEY or UNIQUE constraints shall
contain an SQL NULL value.
HLR H30360
For each SQL index in the database, the schema table of a well-formed
database shall contain a record with the first field set to the text
value "index" and the second field set to a text value containing the
name of the SQL index.
HLR H30370
In a well-formed database, the third field of all schema table
records associated with SQL indexes shall contain the name of the
SQL table that the index applies to.
HLR H30380
In a well-formed database, the fourth field of all schema table
records associated with SQL indexes shall contain the page number
(an integer value) of the root page of the associated index B-Tree
structure.
HLR H30390
In a well-formed database, the fifth field of all schema table
records associated with SQL indexes shall contain an SQL "CREATE
INDEX" statement (a text value). The details of the statement shall
be such that executing the statement would create an index of
precisely the same name and content as the existing database index.
HLR H30400
For each SQL view in the database, the schema table of a well-formed
database shall contain a record with the first field set to the text
value "view" and the second field set to a text value containing the
name of the SQL view.
HLR H30410
In a well-formed database, the third field of all schema table
records associated with SQL views shall contain the same value as
the second field.
HLR H30420
In a well-formed database, the third field of all schema table
records associated with SQL views shall contain the integer value 0.
HLR H30430
In a well-formed database, the fifth field of all schema table
records associated with SQL indexes shall contain an SQL "CREATE
VIEW" statement (a text value). The details of the statement shall
be such that executing the statement would create a view of
precisely the same name and definition as the existing database view.
HLR H30440
For each SQL trigger in the database, the schema table of a well-formed
database shall contain a record with the first field set to the text
value "trigger" and the second field set to a text value containing the
name of the SQL trigger.
HLR H30450
In a well-formed database, the third field of all schema table
records associated with SQL triggers shall contain the name of the
database table or view to which the trigger applies.
HLR H30460
In a well-formed database, the third field of all schema table
records associated with SQL triggers shall contain the integer value 0.
HLR H30470
In a well-formed database, the fifth field of all schema table
records associated with SQL indexes shall contain an SQL "CREATE
TRIGGER" statement (a text value). The details of the statement shall
be such that executing the statement would create a trigger of
precisely the same name and definition as the existing database trigger.
HLR H30480
In an auto-vacuum database, all pages that occur before the page
number stored in the auto-vacuum last root-page field
of the database file header (see H30140) must be either B-Tree root
pages, pointer-map pages or the locking page.
HLR H30490
In an auto-vacuum database, no B-Tree root pages may occur
on or after the page number stored in the auto-vacuum last root-page field
of the database file header (see H30140) must be either B-Tree root
pages, pointer-map pages or the locking page.
HLR H30500
As well as the schema table, a well-formed database file
contains N table B-Tree structures, where N is the
number of non-virtual tables in the logical database, excluding the
sqlite_master table but including sqlite_sequence and other system
tables.
HLR H30510
A well-formed database file contains N table B-Tree structures,
where N is the number of indexes in the logical database,
including indexes created by UNIQUE or PRIMARY KEY clauses in the
declaration of SQL tables.
HLR H30520
A 64-bit signed integer value stored in variable length integer
format consumes from 1 to 9 bytes of space.
HLR H30530
The most significant bit of all bytes except the last in a serialized
variable length integer is always set. Unless the serialized
form consumes the maximum 9 bytes available, then the most significant
bit of the final byte of the representation is always cleared.
HLR H30540
The eight least significant bytes of the 64-bit twos-complement
representation of a value stored in a 9 byte variable length
integer are stored in the final byte (byte offset 8) of the
serialized variable length integer. The other 56 bits are
stored in the 7 least significant bits of each of the first 8 bytes
of the serialized variable length integer, in order from
most significant to least significant.
HLR H30550
A variable length integer that consumes less than 9 bytes of
space contains a value represented as an N-bit unsigned
integer, where N is equal to the number of bytes consumed by
the serial representation (between 1 and 8) multiplied by 7. The
N bits are stored in the 7 least significant bits of each
byte of the serial representation, from most to least significant.
HLR H30560
A database record consists of a database record header,
followed by database record data. The first part of the
database record header is a variable length integer
containing the total size (including itself) of the header in bytes.
HLR H30570
Following the length field, the remainder of the database record
header is populated with N variable length integer
fields, where N is the number of database values stored in
the record.
HLR H30580
Following the database record header, the database record
data is made up of N variable length blobs of data, where
N is again the number of database values stored in the record.
The n blob contains the data for the nth value in
the database record. The size and format of each blob of data is
encoded in the corresponding variable length integer field
in the database record header.
HLR H30590
A value of 0 stored within the database record header indicates
that the corresponding database value is an SQL NULL. In this case
the blob of data in the data area is 0 bytes in size.
HLR H30600
A value of 1 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 1-byte
big-endian signed integer.
HLR H30610
A value of 2 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 2-byte
big-endian signed integer.
HLR H30620
A value of 3 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 3-byte
big-endian signed integer.
HLR H30630
A value of 4 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 4-byte
big-endian signed integer.
HLR H30640
A value of 5 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 6-byte
big-endian signed integer.
HLR H30650
A value of 6 stored within the database record header indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 8-byte
big-endian signed integer.
HLR H30660
A value of 7 stored within the database record header indicates
that the corresponding database value is an SQL real (floating
point number). In this case the blob of data contains an 8-byte
IEEE floating point number, stored in big-endian byte order.
HLR H30670
A value of 8 stored within the database record header indicates
that the corresponding database value is an SQL integer, value 0.
In this case the blob of data in the data area is 0 bytes in size.
HLR H30680
A value of 9 stored within the database record header indicates
that the corresponding database value is an SQL integer, value 1.
In this case the blob of data in the data area is 0 bytes in size.
HLR H30690
An even value greater than or equal to 12 stored within the
database record header indicates that the corresponding
database value is an SQL blob field. The blob of data contains the
value data. The blob of data is exactly (n-12)/2 bytes
in size, where n is the integer value stored in the
database record header.
HLR H30700
An odd value greater than or equal to 13 stored within the
database record header indicates that the corresponding
database value is an SQL text field. The blob of data contains the
value text stored using the database encoding, with no
nul-terminator. The blob of data is exactly (n-12)/2 bytes
in size, where n is the integer value stored in the
database record header.
HLR H30710
In a well-formed database file, if the values 8 or 9 appear within
any database record header within the database, then the
schema-layer file format (stored at byte offset 44 of the
database file header) must be set to 4.
HLR H30720
In a well-formed database file, the values 10 and 11, and all
negative values may not appear within any database record header
in the database.
HLR H30730
The pages in an index B-Tree structures are arranged into a tree
structure such that all leaf pages are at the same depth.
HLR H30740
Each leaf node page in an index B-Tree contains one or more
B-Tree cells, where each cell contains a database record.
HLR H30750
Each internal node page in an index B-Tree contains one or more
B-Tree cells, where each cell contains a child page number, C,
and a database record R. All database records stored within
the sub-tree headed by page C are smaller than record R,
according to the index sort order (see below). Additionally, unless
R is the smallest database record stored on the internal node
page, all integer keys within the sub-tree headed by C are
greater than R-1, where R-1 is the
largest database record on the internal node page that is smaller
than R.
HLR H30760
As well as child page numbers associated with B-Tree cells, each
internal node page in an index B-Tree contains the page number
of an extra child page, the right-child page. All database
records stored in all B-Tree cells within the sub-tree headed by the
right-child page are greater than all database records
stored within B-Tree cells on the internal node page.
HLR H30770
In a well-formed database, each index B-Tree contains a single entry
for each row in the indexed logical database table.
HLR H30780
Each database record (key) stored by an index B-Tree in a
well-formed database contains the same number of values, the number
of indexed columns plus one.
HLR H30790
The final value in each database record (key) stored by an
index B-Tree in a well-formed database contains the rowid (an integer
value) of the corresponding logical database row.
HLR H30800
The first N values in each database record (key)
stored in an index B-Tree where N is the number of indexed
columns, contain the values of the indexed columns from the
corresponding logical database row, in the order specified for the
index.
HLR H30810
The b-tree page flags field (the first byte) of each database
page used as an internal node of an index B-Tree structure is set to
0x02.
HLR H30820
The b-tree page flags field (the first byte) of each database
page used as a leaf node of an index B-Tree structure is set to 0x0A.
HLR H30830
The first byte of each database page used as a B-Tree page contains
the b-tree page flags field. On page 1, the b-tree page
flags field is stored directly after the 100 byte file header
at byte offset 100.
HLR H30840
The number of B-Tree cells stored on a B-Tree page is stored as a
2-byte big-endian integer starting at byte offset 3 of the B-Tree
page. On page 1, this field is stored at byte offset 103.
HLR H30850
The 2-byte big-endian integer starting at byte offset 5 of each
B-Tree page contains the byte-offset from the start of the page
to the start of the cell content area, which consumes all space
from this offset to the end of the usable region of the page.
On page 1, this field is stored at byte offset 105. All B-Tree
cells on the page are stored within the cell-content area.
HLR H30860
On each page used as an internal node a of B-Tree structures, the
page number of the rightmost child node in the B-Tree structure is
stored as a 4-byte big-endian unsigned integer beginning at byte
offset 8 of the database page, or byte offset 108 on page 1.
HLR H30870
Immediately following the page header on each B-Tree page is the
cell offset array, consisting of N 2-byte big-endian
unsigned integers, where N is the number of cells stored
on the B-Tree page (H30840). On an internal node B-Tree page,
the cell offset array begins at byte offset 12, or on a leaf
page, byte offset 8. For the B-Tree node on page 1, these
offsets are 112 and 108, respectively.
HLR H30880
The cell offset array and the cell content area (H30850)
may not overlap.
HLR H30890
Each value stored in the cell offset array must be greater
than or equal to the offset to the cell content area (H30850),
and less than the database page size.
HLR H30900
The N values stored within the cell offset array are the
byte offsets from the start of the B-Tree page to the beginning of
each of the N cells stored on the page.
HLR H30910
No two B-Tree cells may overlap.
HLR H30920
Within the cell content area, all blocks of contiguous
free-space (space not used by B-Tree cells) greater than 3 bytes in
size are linked together into a linked list, the free block list.
Such blocks of free space are known as free blocks.
HLR H30930
The first two bytes of each free block contain the offset
of the next free block in the free block list formatted
as a 2-byte big-endian integer, relative to the start of the database
page. If there is no next free block, then the first two
bytes are set to 0x00.
HLR H30940
The second two bytes (byte offsets 2 and 3) of each free block
contain the total size of the free block, formatted as a 2-byte
big-endian integer.
HLR H30950
On all B-Tree pages, the offset of the first free block in the
free block list, relative to the start of the database page,
is stored as a 2-byte big-endian integer starting at byte offset
1 of the database page. If there is no first free block
(because the free block list is empty), then the two bytes
at offsets 1 and 2 of the database page are set to 0x00. On page 1,
this field is stored at byte offset 101 of the page.
HLR H30960
Within the cell-content area, all blocks of contiguous free-space
(space not used by B-Tree cells) less than or equal to 3 bytes in
size are known as fragments. The total size of all
fragments on a B-Tree page is stored as a 1-byte unsigned
integer at byte offset 7 of the database page. On page 1, this
field is stored at byte offset 107.
HLR H30970
Each B-Tree cell belonging to an internal node page of an index
B-Tree consists of a 4-byte big-endian unsigned integer, the
child page number, followed by a variable length integer
field, followed by a database record. The
variable length integer field contains the length of the
database record in bytes.
HLR H30980
Each B-Tree cell belonging to an leaf page of an index B-Tree
consists of a variable length integer field, followed by
a database record. The variable length integer field
contains the length of the database record in bytes.
HLR H30990
If the database record stored in an index B-Tree page is
sufficiently small, then the entire cell is stored within the
index B-Tree page. Sufficiently small is defined as equal to or
less than max-local, where:
max-local := (usable-size - 12) * 64 / 255 - 23
HLR H31000
If the database record stored as part of an index B-Tree cell is too
large to be stored entirely within the B-Tree page (as defined by
H30520), then only a prefix of the database record is stored
within the B-Tree page and the remainder stored in an overflow
chain. In this case, the database record prefix is immediately
followed by the page number of the first page of the
overflow chain, formatted as a 4-byte big-endian unsigned
integer.
HLR H31010
When a database record belonging to a table B-Tree cell is
stored partially within an overflow page chain, the size
of the prefix stored within the index B-Tree page is N bytes,
where N is calculated using the following algorithm:
min-local := (usable-size - 12) * 32 / 255 - 23
max-local := (usable-size - 12) * 64 / 255 - 23
N := min-local + ((record-size - min-local) % (usable-size - 4))
if( N > max-local ) N := min-local
HLR H31020
The pages in a table B-Tree structures are arranged into a tree
structure such that all leaf pages are at the same depth.
HLR H31030
Each leaf page in a table B-Tree structure contains one or more
B-Tree cells, where each cell contains a 64-bit signed integer key
value and a database record.
HLR H31040
Each internal node page in a table B-Tree structure contains one or
more B-Tree cells, where each cell contains a 64-bit signed integer
key value, K, and a child page number, C. All integer key
values in all B-Tree cells within the sub-tree headed by page C
are less than or equal to K. Additionally, unless K
is the smallest integer key value stored on the internal node page,
all integer keys within the sub-tree headed by C are greater
than K-1, where K-1 is the largest
integer key on the internal node page that is smaller than K.
HLR H31050
As well as child page numbers associated with B-Tree cells, each
internal node page in a table B-Tree contains the page number
of an extra child page, the right-child page. All key values
in all B-Tree cells within the sub-tree headed by the right-child
page are greater than all key values stored within B-Tree cells
on the internal node page.
HLR H31060
In a well-formed database, each table B-Tree contains a single entry
for each row in the corresponding logical database table.
HLR H31070
The key value (a 64-bit signed integer) for each B-Tree entry is
the same as the value of the rowid field of the corresponding
logical database row.
HLR H31080
The SQL values serialized to make up each database record
stored as ancillary data in a table B-Tree shall be the equal to the
values taken by the N leftmost columns of the corresponding
logical database row, where N is the number of values in the
database record.
HLR H31090
If a logical database table column is declared as an "INTEGER
PRIMARY KEY", then instead of its integer value, an SQL NULL
shall be stored in its place in any database records used as
ancillary data in a table B-Tree.
HLR H31100
If the database schema layer file-format (the value stored
as a 4-byte integer at byte offset 44 of the file header) is 1,
then all database records stored as ancillary data in a table
B-Tree structure have the same number of fields as there are
columns in the corresponding logical database table.
HLR H31110
If the database schema layer file-format value is two or
greater and the rightmost M columns of a row contain SQL NULL
values, then the corresponding record stored as ancillary data in
the table B-Tree has between N-M and N fields,
where N is the number of columns in the logical database
table.
HLR H31120
If the database schema layer file-format value is three or
greater and the rightmost M columns of a row contain their
default values according to the logical table declaration, then the
corresponding record stored as ancillary data in the table B-Tree
may have as few as N-M fields, where N is the
number of columns in the logical database table.
HLR H31130
In a well-formed database file, the first byte of each page used
as an internal node of a table B-Tree structure is set to 0x05.
HLR H31140
In a well-formed database file, the first byte of each page used
as a leaf node of a table B-Tree structure is set to 0x0D.
HLR H31150
B-Tree cells belonging to table B-Tree internal node pages consist
of exactly two fields, a 4-byte big-endian unsigned integer
immediately followed by a variable length integer. These
fields contain the child page number and key value respectively
(see H31030).
HLR H31160
B-Tree cells belonging to table B-Tree leaf node pages consist
of three fields, two variable length integer values
followed by a database record. The size of the database record
in bytes is stored in the first of the two
variable length integer fields. The second of the two
variable length integer fields contains the 64-bit signed
integer key (see H31030).
HLR H31170
If the size of the record stored in a table B-Tree leaf page cell
is less than or equal to (usable page size-35) bytes, then
the entire cell is stored on the B-Tree leaf page. In a well-formed
database, usable page size is the same as the database
page size.
HLR H31180
If a table B-Tree cell is too large to be stored entirely on
a leaf page (as defined by H31170), then a prefix of the cell
is stored on the leaf page, and the remainder stored in an
overflow page chain. In this case the cell prefix
stored on the B-Tree leaf page is immediately followed by a
4-byte big-endian unsigned integer containing the page number
of the first overflow page in the chain.
HLR H31190
When a table B-Tree cell is stored partially in an
overflow page chain, the prefix stored on the B-Tree
leaf page consists of the two variable length integer fields,
followed by the first N bytes of the database record, where
N is determined by the following algorithm:
min-local := (usable-size - 12) * 32 / 255 - 23
max-local := (usable-size - 35)
N := min-local + (record-size - min-local) % (usable-size - 4)
if( N > max-local ) N := min-local
HLR H31200
A single overflow page may store up to available-space
bytes of database record data, where available-space is equal
to (usable-size - 4).
HLR H31210
When a database record is too large to store within a B-Tree page
(see H31170 and H31000), a prefix of the record is stored within
the B-Tree page and the remainder stored across N overflow
pages. In this case N is the minimum number of pages required
to store the portion of the record not stored on the B-Tree page,
given the maximum payload per overflow page defined by H31200.
HLR H31220
The list of overflow pages used to store a single database record
are linked together in a singly linked list known as an
overflow chain. The first four bytes of each page except the
last in an overflow chain are used to store the page number
of the next page in the linked list, formatted as an unsigned
big-endian integer. The first four bytes of the last page in an
overflow chain are set to 0x00.
HLR H31230
Each overflow page except the last in an overflow chain
contains N bytes of record data starting at byte offset 4 of
the page, where N is the maximum payload per overflow page,
as defined by H31200. The final page in an overflow chain
contains the remaining data, also starting at byte offset 4.
HLR H31240
All free pages in a well-formed database file are part of
the database free page list.
HLR H31250
Each free page is either a free list trunk page or a
free list leaf page.
HLR H31260
All free list trunk pages are linked together into a singly
linked list. The first 4 bytes of each page in the linked list
contains the page number of the next page in the list, formatted
as an unsigned big-endian integer. The first 4 bytes of the last
page in the linked list are set to 0x00.
HLR H31270
The second 4 bytes of each free list trunk page contains
the number of free list leaf page numbers stored on the free list
trunk page, formatted as an unsigned big-endian integer.
HLR H31280
Beginning at byte offset 8 of each free list trunk page are
N page numbers, each formatted as a 4-byte unsigned big-endian
integers, where N is the value described in requirement H31270.
HLR H31290
All page numbers stored on all free list trunk pages refer to
database pages that are free list leaves.
HLR H31300
The page number of each free list leaf page in a well-formed
database file appears exactly once within the set of pages numbers
stored on free list trunk pages.
HLR H31310
The total number of pages in the free list, including all free list
trunk and free list leaf pages, is stored as a 4-byte unsigned
big-endian integer at offset 36 of the database file header.
HLR H31320
The page number of the first page in the linked list of free list
trunk pages is stored as a 4-byte big-endian unsigned integer at
offset 32 of the database file header. If there are no free list
trunk pages in the database file, then the value stored at
offset 32 of the database file header is 0.
HLR H31330
Non auto-vacuum databases do not contain pointer map pages.
HLR H31340
In an auto-vacuum database file, every (num-entries + 1)th
page beginning with page 2 is designated a pointer-map page, where
num-entries is calculated as:
num-entries := database-usable-page-size / 5
HLR H31350
In an auto-vacuum database file, each pointer-map page contains
a pointer map entry for each of the num-entries (defined by
H31340) pages that follow it, if they exist.
HLR H31360
Each pointer-map page entry consists of a 1-byte page type and a
4-byte page parent number, 5 bytes in total.
HLR H31370
Pointer-map entries are packed into the pointer-map page in order,
starting at offset 0. The entry associated with the database
page that immediately follows the pointer-map page is located at
offset 0. The entry for the following page at offset 5 etc.
HLR H31380
For each page except page 1 in an auto-vacuum database file that is
the root page of a B-Tree structure, the page type of the
corresponding pointer-map entry is set to the value 0x01 and the
parent page number is zero.
HLR H31390
For each page that is a part of an auto-vacuum database file free-list,
the page type of the corresponding pointer-map entry is set to the
value 0x02 and the parent page number is zero.
HLR H31400
For each page in a well-formed auto-vacuum database that is the first
page in an overflow chain, the page type of the corresponding
pointer-map entry is set to 0x03 and the parent page number field
is set to the page number of the B-Tree page that contains the start
of the B-Tree cell stored in the overflow-chain.
HLR H31410
For each page that is the second or a subsequent page in an overflow
chain, the page type of the corresponding pointer-map entry is set to
0x04 and the parent page number field is set to the page number of the
preceding page in the overflow chain.
HLR H31420
For each page that is not a root page but is a part of a B-Tree tree
structure (not part of an overflow chain), the page type of the
corresponding pointer-map entry is set to the value 0x05 and the parent
page number field is set to the page number of the parent node in the
B-Tree structure.
HLR H32000
If a journal file contains a well-formed master-journal pointer and the
named master-journal file does not exist then the journal file shall be
considered invalid.
HLR H32010
If the first 28 bytes of a journal file do not contain a well-formed
journal header, then the journal file shall be considered
invalid.
HLR H32020
If the journal file exists within the file-system and neither H32000
, H32010 nor H33080 apply, then the journal file shall be considered valid.
HLR H32030
If there exists a valid journal file in the file-system, then the
database page-size in bytes used to interpret the database image
shall be the value stored as a 4-byte big-endian unsigned integer at byte
offset 24 of the journal file.
HLR H32040
If there exists a valid journal file in the file-system, then the
number of pages in the database image shall be the value stored as
a 4-byte big-endian unsigned integer at byte offset 24 of the
journal file.
HLR H32050
If there is no valid journal file in the file-system, then the
database page-size in bytes used to interpret the database image
shall be the value stored as a 2-byte big-endian unsigned integer at byte
offset 16 of the database file.
HLR H32060
If there is no valid journal file in the file-system, then the
number of pages in the database image shall be calculated by dividing
the size of the database file in bytes by the database page-size.
HLR H32070
If there exists a valid journal file in the file-system, then the
contents of each page of the database image for which there is a valid
journal record in the journal file shall be read from the
corresponding journal record.
HLR H32080
The contents of all database image pages for which there is no valid
journal record shall be read from the database file.
HLR H32090
A buffer of 28 bytes shall be considered a well-formed journal
header if it is not excluded by requirements H32180, H32190 or H32200.
HLR H32180
A buffer of 28 bytes shall only be considered a well-formed journal
header if the first eight bytes of the buffer contain the values 0xd9,
0xd5, 0x05, 0xf9, 0x20, 0xa1, 0x63, and 0xd7, respectively.
HLR H32190
A buffer of 28 bytes shall only be considered a well-formed journal
header if the value stored in the sector size field (the 4-byte big-endian
unsigned integer at offset 20 of the buffer) contains a value that
is an integer power of two greater than 512.
HLR H32200
A buffer of 28 bytes shall only be considered a well-formed journal
header if the value stored in the page size field (the 4-byte big-endian
unsigned integer at offset 24 of the buffer) contains a value that
is an integer power of two greater than 512.
HLR H32100
A buffer of (8 + page size) bytes shall be considered a well-formed journal
record if it is not excluded by requirements H32110 or H32120.
HLR H32110
A journal record shall only be considered to be well-formed if the page number
field contains a value other than zero and the locking-page number, calculated
using the page size found in the first journal header of the journal file that
contains the journal record.
HLR H32120
A journal record shall only be considered to be well-formed if the checksum
field contains a value equal to the sum of the value stored in the
checksum-initializer field of the journal header that precedes the record
and the value stored in every 200th byte of the page data field, interpreted
as an 8-bit unsigned integer), starting with byte offset (page-size % 200) and
ending with the byte at byte offset (page-size - 200).
HLR H32130
A buffer shall be considered to contain a well-formed master journal pointer
record if it is not excluded from this category by requirements H32140,
H32150, H32160 or H32170.
HLR H32140
A buffer shall only be considered to be a well-formed master journal pointer
if the final eight bytes of the buffer contain the values 0xd9, 0xd5, 0x05,
0xf9, 0x20, 0xa1, 0x63, and 0xd7, respectively.
HLR H32150
A buffer shall only be considered to be a well-formed master journal pointer
if the size of the buffer in bytes is equal to the value stored as a 4-byte
big-endian unsigned integer starting 16 bytes before the end of the buffer.
HLR H32160
A buffer shall only be considered to be a well-formed master journal pointer
if the first four bytes of the buffer, interpreted as a big-endian unsigned
integer, contain the page number of the locking page (the value
(1 + 230 / page-size), where page-size is the value stored in
the page-size field of the first journal header of the journal file).
HLR H32170
A buffer shall only be considered to be a well-formed master journal pointer
if the value stored as a 4-byte big-endian integer starting 12 bytes before
the end of the buffer is equal to the sum of all bytes, each interpreted
as an 8-bit unsigned integer, starting at offset 4 of the buffer and continuing
until offset (buffer-size - 16) (the 17th last byte of the buffer).
HLR H32210
A buffer shall be considered to contain a well-formed journal section
if it is not excluded from this category by requirements H32220, H32230 or
H32240.
HLR H32220
A buffer shall only be considered to contain a well-formed journal section
if the first 28 bytes of it contain a well-formed journal header.
HLR H32230
A buffer shall only be considered to contain a well-formed journal section
if, beginning at byte offset sector-size, it contains a sequence of
record-count well-formed journal records. In this case sector-size and
record-count are the integer values stored in the sector size and record
count fields of the journal section's journal header.
HLR H32240
A buffer shall only be considered to contain a well-formed journal section
if it is an integer multiple of sector-size bytes in size, where sector-size
is the value stored in the sector size field of the journal section's journal
header.
HLR H32250
A journal record found within a valid journal file shall be considered a valid
journal record if it is not excluded from this category by requirement H32260,
H32270 or H32280.
HLR H32260
A journal record shall only be considered a valid journal record if it and any
other journal records that occur before it within the same journal section are
well-formed.
HLR H32270
A journal record shall only be considered a valid journal record if the journal
section to which it belongs begins with a well-formed journal header.
HLR H32280
A journal record shall only be considered a valid journal record if all journal
sections that occur before the journal section containing the journal record
are well-formed journal sections.
HLR H32290
Two database images shall be considered to be equivalent if they (a) have the
same page size, (b) contain the same number of pages and (c) the content of
each page of the first database image that is not a free-list leaf page is
the same as the content of the corresponding page in the second database image.
HLR H32300
If, while writing to an SQLite database file-system representation in
order to replace database image A with database image B, a failure that
should be handled gracefully occurs, then following recovery the database
file-system representation shall contain a database image equivalent to
either A or B.
HLR H32320
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that before the size of
the database file is modified, the first 28 bytes of the journal file contain a
stable valid journal header with the page-size and page-count fields set to
values corresponding to the original database image.
HLR H32330
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that the first 28 bytes
of the journal file does not become unstable at any point after the size of the
database file is modified until the journal file is invalidated to commit the
transaction.
HLR H32340
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that before any part of
the database file that contained a page of the original database image that was
not a free-list leaf page is overwritten or made unstable the journal file
contains a valid and stable journal record containing the original page data.
HLR H32350
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that after any part of
the database file that contained a page of the original database image that was
not a free-list leaf page has been overwritten or made unstable the corresponding
journal record (see H32340) is not modified or made unstable.
HLR H32360
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that before the database
file is truncated, the journal file contains stable valid journal records
corresponding to all pages of the original database image that were part of the
region being discarded by the truncate operation and were not free-list leaf
pages.
HLR H32370
When using the rollback-journal method to modify the file-system representation
of a database image, the database writer shall ensure that after the database
file has been truncated the journal records corresponding to pages from the
original database image that were part of the truncated region and were not
free-list leaf pages are not modified or made unstable.
HLR H33000
Before reading from a database file , a database reader shall establish a
SHARED or greater lock on the database file-system representation.
HLR H33010
Before writing to a database file, a database writer shall establish
an EXCLUSIVE lock on the database file-system representation.
HLR H33020
Before writing to a journal file, a database writer shall establish
a RESERVED, PENDING or EXCLUSIVE lock on the database file-system
representation.
HLR H33030
Before establishing a RESERVED or PENDING lock on a database file, a
database writer shall ensure that the database file contains a valid
database image.
HLR H33060
Before establishing a RESERVED or PENDING lock on a database file, a
database writer shall ensure that any journal file that may be present
is not a valid journal file.
HLR H33080
If another database client holds either a RESERVED or PENDING lock on the
database file-system representation, then any journal file that exists within
the file system shall be considered invalid.
HLR H33040
A database writer shall increment the value of the database header change
counter field, a 4-byte big-endian unsigned integer field stored at byte offset 24
of the database header, as part of the first database image modification
that it performs after obtaining an EXCLUSIVE lock.
HLR H33050
A database writer shall increment the value of the database schema version
field, a 4-byte big-endian unsigned integer field stored at byte offset 40
of the database header, as part of the first database image modification that
includes a schema change that it performs after obtaining an EXCLUSIVE lock.
HLR H33070
If a database writer is required by either H33050 or H33040 to increment a
database header field, and that header field already contains the maximum
value possible (0xFFFFFFFF, or 4294967295 for 32-bit unsigned integer
fields), "incrementing" the field shall be interpreted to mean setting it to
zero.