On Tue, 18 Apr 2017, Jens Alfke wrote:
On Apr 18, 2017, at 2:20 AM, Deon Brewis <de...@outlook.com> wrote:
It's not like it was subtle - it's a dead on repro. I was able to repro this by
doing a power cycle 2 hours after shutting the app down. OSX didn't seem to
have any interest in flushing mmap files until you soft reboot the machine.
OK, hang on — I just reread the docs on memory-mapped I/O in SQLite.
Memory-mapping is *only used for reads*, never for writes:
When updating the database file, SQLite always makes a copy of the page content
into heap memory before modifying the page. This is necessary for two reasons.
First, changes to the database are not supposed to be visible to other
processes until after the transaction commits and so the changes must occur in
private memory. Second, SQLite uses a read-only memory map to prevent stray
pointers in the application from overwriting and corrupting the database file.
— https://www.sqlite.org/mmap.html
Therefore I can’t imagine how using it could trigger database corruption. It
doesn’t affect the way data is written at all!
If the filesystem implementation is not fully-coherent, then data
written by programmed file I/O may not be reflected in the memory
mapped space, resulting in programs using something other than what is
in the file, resulting in wrong data being written to the file.
GraphicsMagick has a configure test for this and some operating
systems fail the test. Sqlite3 is free to adopt this same test.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
