Due to the fact that you want to iterate over all keys that are before or equal to `max` starting from `min` the bytes.Compare() check should look like the commit suggests.
This commit fixes an issue with ext3/ext4 filesystems where metadata file size is not synced
when resizing a file. It also resizes the entire resize instead of updating the size during
individual page writes.
Thanks to @tv42 for the fix.
The max mmap size was previous unchecked which resulted in a panic once
the maximum size was reached. This commit adds a check for the max size
when re-mapping and returns an error if the new map will exceed the size.
Thanks to Tamás Gulácsi for testing out the change on i386.
The import and export commands are a relic of early Bolt when the file
format was not stable. If the file format changed then users could export
their old data and import it into a new database with a new format.
The Bolt DB file format is stable and will not change so this command is no
longer needed.
Thanks to Alejandro Gaviria for pointing this out.
OpenBSD does not include a UBC kernel and writes must be synchronized
with the msync(2) syscall. In addition, the NoSync field of the DB
struct should be ignored on OpenBSD, since unlike other platforms,
missing msyncs will result in data corruption.
Depends on PR #258.
Fixes#257.
Rather than having the build setup such that it will only work on the
specifically defined operating systems, this commit modifies it to use
more liberal !windows,!plan9 build tag for the unix specific bits.
This means bolt will compile on more Operating Systems such as OpenBSD,
FreeBSD, and NetBSD.
See boltdb/bolt#257 for discussion.
This commit adds a caveat for high memory usage shown by processes with large
Bolt databases. This is expected behavior and is handled by the OS page cache.
This commit adds a caveat to the README to notify users that bulk loading
random writes into a single new bucket can be problematic. This issue was
reported by @freepk.
Fixes#244.
This commit fixes a bug that occurs when a root node is split just after a re-mmap occurs.
Previously, this would cause a panic because the new root node would still reference
keys from the old mmap.
