[sqlite] The Lock-Byte Page
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.
[sqlite] The Lock-Byte Page
> Le 28 d?c. 2015 ? 08:27, Dan Kennedy a ?crit : > > 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. Thank you Dan for this authoritative answer. :) It's perfectly clear now. > 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. I suspected this, but I didn't have to use file locking APIs for so many years (lucky me!), so I really wasn't sure at all about this. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om
[sqlite] The Lock-Byte Page
> Le 27 d?c. 2015 ? 23:17, Simon Slavin a ?crit : > > These bytes can be used by a VFS designed to run on those operating systems > to allow communication between processes about lock status. Thanks a lot for the whole explanation Simon. Much clearer now. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om
[sqlite] The Lock-Byte Page
Hello, I'm referring to paragraph 1.3 of https://www.sqlite.org/fileformat2.html about the Lock-Byte page.
[sqlite] The Lock-Byte Page
On 27 Dec 2015, at 10:08pm, Olivier Mascia wrote: > 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? Some operating systems for unusual operating systems or embedded devices use file APIs which top out at 2^30 bytes (signed integer 32 bits long). They have great difficulty in handling database which are longer than that many bytes, including trying to simulate locks on parts of those files. These bytes can be used by a VFS designed to run on those operating systems to allow communication between processes about lock status. If you are not writing your own VFS to run in a 31-bit file system then you should avoid using these bytes. This includes cases where you're not writing a VFS and cases where your VFS runs on a normal multipurpose desktop computer with a 32-bit or 64-bit file system. Simon.
