You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my case, I need to merge values with flatbuffers builder, which returns &[u8] that refers to inner object of the builder.
In order to pass this &[u8] to rocksdb, I have to copy it to a new Vec<[u8]>, which will be copied again in the full_merge_callback, and will be copied once more by rocksdb itself.
In this case, the buffer would be copied 3 times.
It would be better to allow MergeFn return just &[u8], and because rocksdb would immediately copy it into its memtable in an synchrounous way, the memory should be safe, IMHO.
The text was updated successfully, but these errors were encountered:
and because rocksdb would immediately copy it into its memtable in an synchrounous way, the memory should be safe, IMHO.
I don't think it is true. @aleksuss looks like UB, huh?
Hi, thanks for your reply. Based on my reading on the rocksdb's C API impl (https://github.com/facebook/rocksdb/blob/master/db/c.cc#L370), the returned raw buffer will be copied into the MergeOperationOutput::new_value field (which is a std::string) immediately.
rleungx
pushed a commit
to rleungx/rust-rocksdb
that referenced
this issue
Jun 17, 2020
In my case, I need to merge values with flatbuffers builder, which returns &[u8] that refers to inner object of the builder.
In order to pass this &[u8] to rocksdb, I have to copy it to a new Vec<[u8]>, which will be copied again in the full_merge_callback, and will be copied once more by rocksdb itself.
In this case, the buffer would be copied 3 times.
It would be better to allow MergeFn return just &[u8], and because rocksdb would immediately copy it into its memtable in an synchrounous way, the memory should be safe, IMHO.
The text was updated successfully, but these errors were encountered: