On 12/28/2015 05:08 AM, Olivier Mascia wrote: > Hello, > > I'm referring to paragraph 1.3 of https://www.sqlite.org/fileformat2.html > about the Lock-Byte page. > > From what I read, I understand those 2^9 bytes at offset 2^30, should they > exist, are set aside, untouched by SQLite nor the built-in unix and win32 > VFS, but third-party VFS implementations might. > > What I don't really get straight is what file-locking related mechanism would > have a use for those bytes, knowing they wouldn't even exists unless the > database size is 2^30 bytes or more? Or should I understand that for > whatever purpose they could be used for, only their offset is useful (even > when those bytes do not exists in the file)?
It's because (at least historically - may have changed?) win32 does not support advisory locks. So if you take an EXCLUSIVE lock on a range of bytes no other process can read them. This is different from Unix, where all locks are advisory - one process locking a range of bytes does not prevent another from reading them, only from taking a conflicting lock. For this reason we need a range of bytes that are never read by SQLite to take locks on (otherwise we couldn't have readers running concurrently with the writer). The reason the selected range is out at 2^30 instead of, say, at the start of the file, is to avoid forcing really small databases to be larger than they would otherwise have to be. It doesn't matter that database files are usually less than 2^30 bytes in size. All the (main?) platforms support locking regions of a file that have not yet been populated. Dan.
