On 04/19/2017 02:42 AM, 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:
It was used for writes in versions before 3.10.0 (January 2016). And
still is if SQLITE_MMAP_READWRITE is defined (not the default).
Dan.
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!
I accept that both of you have experimentally seen that memory-mapping leads to
corruption, so I can only assume that either the above documentation is wrong,
or that there’s some subtle bug in SQLite that alters the way data is written
when memory-mapping is enabled.
—Jens
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
