I have been bitten by this when running a simple application on a
Raspberry Pi 2. It had 3 stores: two 512M stores and one 128M. The
application refused to start the moment the first index grew from 512M
to 1G.
Bolt is really nice but it is easy to overlook this limitation,
especially with the note about supporting stores much larger than
*physical* memory.
This commit adds documentation to clarify that read-only and read-write
transactions should not be mixed in the same goroutine as it can cause
deadlocks during remapping.
See: https://github.com/boltdb/bolt/issues/378
Added a few lines of documentation to clarify that read-only
transactions need to be rolled back and not committed, as per the
discussion in issue #344
This commit adds safety documentation to the data accessor functions
in Bolt as well as the README. This was documented once in the package
level godoc but it's important enough that it should be more clear.
This commit moves the functionality in Tx.Copy() to Tx.WriteTo(). This
allows Tx to be used as an io.WriterTo which makes it easier to mock.
The Tx.Copy() function still exists but it's simply a wrapper around
Tx.WriteTo().
DB.Batch makes it easy to make lots of small transactions with
significantly better performance. Batch combines multiple concurrent
Update calls into a single disk transaction, managing errors smartly.
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 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.