happen during memory allocation. No problems fixed; this change is just
to make future maintenance easier.
FossilOrigin-Name: 215650a5a1d55bdbca9c92524804a1a54456a17f42a17e53747b21a6507506f5
for inhibiting direct-overflow-read. This check-in fixes the problem.
FossilOrigin-Name: 113078d555eaf740666680562ebbb04f7d823b72e8b2d553627e54ab3d7bf653
SQLITE_DIRECT_OVERFLOW_READ optimization if that capability is missing.
FossilOrigin-Name: f50ae00ce9ff572e6bd5e2788602ba356383526ab7289622a32fbf52926c6df0
SQLITE_DIRECT_OVERFLOW_READ optimization) to use less code and to be
more easily testable.
FossilOrigin-Name: eed670ea2a9424f7df4eeb01c152fc38f7190a5e39aa891651b28dc91fcdc019
This should have appeared on trunk originally and then be cherry-picked onto
the branch. Oh well....
FossilOrigin-Name: ac39800bb2685fa287c7d834faed75f0bc61320ef986de314392d6eadb574d30
calculation. The cast is not strictly necessary, but it helps human readers
see that the code is correct.
FossilOrigin-Name: 7564ff1ba2c2fba89106d1aa06cc5379e752f119f22370f2f155f24cc698dec6
and there is a new freelist page at the end of the database file which would
cause the database file size to grow, ensure that page is written and the
file size grows before the block-atomic-write commits. Fix for the
problem identified by [forum:/forumpost/3bd8d497b2|forum post 3bd8d497b2]
FossilOrigin-Name: c9fdd6805df04f05ef347e5a43506fd37a729c5924abb6e1103e871c4ac2d6dc
journal_mode=MEMORY, attempt to rollback before closing the journal, as
all rollback information is forgotten when a memory rollback journal is
closed.
FossilOrigin-Name: 1d67f75de259e5a26b751a50432822a268ebe367cda6510891ab81a15e5daa1c
mode, to avoid an assertion fault in the new sqlite3_randomness() avoidance
code added by [c84e4483cb44f827].
FossilOrigin-Name: 29937081a986d88f495ad48748c35ff5829f0ac31dd4ad3e48d180ae2fcb9a0c
flag, the pager is opened in journal-mode MEMORY, even if compiled with
SQLITE_OMIT_DESERIALIZE. No changes to the logic as long as that OMIT flag
is omitted. We need to better document the behavior of xOpen to describe this.
FossilOrigin-Name: da1252b29852191eccbea98e0314408c75bb83a51f9d68d589705d4971a23850
already set to RESERVED if the SQLITE_FCNTL_PERSIST_WAL setting is set and
a specific sequence of multiple journal mode changes occur.
Enhance pagerExclusiveLock() to deal with this.
[forum:/forumpost/8130545bc6|Forum post 8130545bc6]
FossilOrigin-Name: 2bb8d977392f635515aa4a36f6f763a2e4858f7adc1120519e2e74c04a9749b5
failure to acquire the page due to it being larger than the maximum page
size. Fix for [forum:/forumpost/a19bb49140|forum post a19bb49140].
FossilOrigin-Name: 982b35563da685dfdf50cbe4a7ae829d3b428e03587028df7efe520f819b1dc2
[forum:forumpost/e3f72e9291189925|Forum post e3f72e9291189925]. The code
was legal and correct. The revised code is actually less clear in its intent.
But at least now there will (hopefully) be no warning.
FossilOrigin-Name: 48bb7c88787bf5de1d70cf3cc81ada38c6c02e476dbdff12c8676c6d5ee19aed
turns out we should never allow a zero key into the pcache interface according
to the design specs, even if that page is immediately released without ever
being used.
FossilOrigin-Name: ec96293ead83603ebe5d7f250d6fdc11f22172f05a9513f175331437c3eaa4c8
into a single spot for small size reduction and performance increase.
FossilOrigin-Name: a1c090e08139f99d30aa89db0756dc59fe8990ce15b3db4d4b726cc6acdab46f
to cover the entire database. Fix for the problem identified by
[forum:/forumpost/3b9e894312|forum post 3b9e894312].
FossilOrigin-Name: 12c012162ce110a7a7fbbe853f422e23cb4ae10b45237727328c8f3315b70842
than computing the page number every time it is needed, because it turns out
that number is needed quite frequently. This saves a few hundred thousand
CPU cycles and a few bytes of code space.
FossilOrigin-Name: 5aa9c3eb45514d5eb7b32696d25a9aeb7dad485e1ea5adb833fac6d1f2105f1a
assert() is not necessarily true if the database size in the header is
wrong. dbsqlfuzz f2f996065b90988aa9b0ae425b66dbb296546a08.
FossilOrigin-Name: a51402e8c29fad2b24e32de55b10691fb0ebd6c2cebac941e43e54be211d5d39
sqlite3_wal_checkpoint() without first performing a transaction, first
try to run a synthesized transaction to get the Pager caught up before
attemptingn the checkpoint.
[forum:/forumpost/fd0f19d229156939|forum post fd0f19d229156939].
FossilOrigin-Name: eee6de1967609f0b590ee4dbec088c3e7b03b08753267ed2909c5b03d60a0e18
file exceed the actual number of pages in the database file, even when
PRAGMA writeable_schema=ON. This helps with earlier detection of corruption,
and prevents excess memory usage and CPU cycles in some integrity_check ops.
FossilOrigin-Name: 0407c8793700491b8519a649b9624f569b0e7e9b94d0db79d4a08139e0ecdb69
such a file exists on disk. See
[forum/forumpost/ec2a102440|forum post ec2a102440] for a description. I so
far have been unable to find any harm to come of the problem, other than the
assertion fault when in DEBUG mode.
FossilOrigin-Name: fdf9ed665b2fb07d26f3852bfd2170f2fb56851edd2851d47672116a8ea58463
