Build and test failures with -DSQLITE_OMIT_WAL
(1.1) By Paul Khuong (pkhuong) on 2021-05-05 13:29:49 edited from 1.0 [source]
I'm playing with a new VFS that targets rollback journal only, using the new atomic batch write interface. When attempting to test it, I ran into a couple issues when building a recent snapshot (FossilOrigin-Name: ea221f3c8e243a5dc4952e510cbe396614a24876bacdc04fb1ebd4127c7ef0d9
) with -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_OMIT_WAL
.
It was no trouble to restore the build and tests locally, but I'd rather not maintain these patches. Are the failures an oversight, or are WAL/mmap-less configurations deprecated?
This is what I found with a regular make test
. If there's interest in fixing these, I can report back any additional failure for make soaktest
.
Build failure in os_unix.c's
unixFileControl
refers tounixFcntlExternalReader
unconditionally, but that function isn't defined with-DSQLITE_OMIT_WAL
.Tests that assume the WAL code is available:
- busy2-1 and busy2-2
- chunksize-2
- corruptL-14.2
- delete_db-1.2.0 and delete_db-1.4.0
- e_wal
- e_walauto
- e_walckpt
- e_walhook
- exclusive-7.1
- interrupt2
- nolock-2.2, nolock-2.12: had to change the expectations around the number of
xAccess
calls - nolock-4
- pager1-4.4, pager1-35
- resetdb
- rowallock
- symlink-2..4, symlink-2..5: had to change the expectations.
- symlink-4.2.1, symlink-4.4.2: WAL-only
- sync2-1.5 through to sync2-1.10.3, and sync2-1.11
- unixexcl-3
- wal9
It seems like oserror should check for
[test_syscall defaultvfs] != "unix"
instead of$::tcl_platform(platform)!="unix"
: builds like mine may override the default VFS but still run on *nix.