2015-05-22 13:28 GMT+05:30 Dan Kennedy <danielk1977 at gmail.com>: > On 05/22/2015 02:37 PM, Mikael wrote: > >> Hi, >> >> If mmap_size is big enough, read() will never be needed, so what about >> enabling mmap on platforms that "lack of a unified buffer cache"? >> >> I mean, on a 64bit platform, setting mmap_size to say 1TB should be fine - >> >> So what about enabling mmap_size on platforms that "lack of a unified >> buffer cache"? >> >> >> Also, if read() by some reason would be needed, there's msync() which is >> like a flush(), so here the "lack of a unified buffer cache" shouldn't be >> an issue anyhow? >> > > I think part of the concern is two processes accessing the same SQLite > database - one using mmap() and one using regular read() and write() calls. >
You mean, the issue would be if two processes had the same SQLite database opened and their mmap_size setting would be different? So SQLite already does msync() so the mmap+read()/write() is not actually an issue within the scope of one OS process, that the mmap and readwrite would go "out of sync" so you'd get data corruption that way? Well if that's the only problem then I guess on OBSD mmap_size can safely be turned on, just with that as precaution to the users i.e. all different OS processes that open one and the same SQLite database *must* have the *exactly* same mmap_size setting, or your file will be fried!? Sounds good to me! In particular that you can just put the mmap_size to 1TB on all instances all over? (as at least on a 64bit machine you have 16.7 million 1TB address spaces available so it's not like a scarce resource) > Just out of interest, is it a specific platform that you're concerned > about? > OBSD just as specifically mentioned on https://www.sqlite.org/mmap.html ! > Dan. >
