From eacb14a10a52afae006a45721dffe7a3bd62738f Mon Sep 17 00:00:00 2001 From: Akanksha Mahajan Date: Thu, 18 Feb 2021 11:40:28 -0800 Subject: [PATCH] Update history.md for bug fix of actual error returned in DB::OpenForReadOnly (#7978) Summary: Update history.md for bug fix of actual error returned in DB::OpenForReadOnly Pull Request resolved: https://github.com/facebook/rocksdb/pull/7978 Reviewed By: jay-zhuang Differential Revision: D26519195 Pulled By: akankshamahajan15 fbshipit-source-id: 39fd2bcc12ab92a492e8254090b742efa377ed51 --- HISTORY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/HISTORY.md b/HISTORY.md index 67b4e1440..871ae2ccc 100644 --- a/HISTORY.md +++ b/HISTORY.md @@ -14,6 +14,7 @@ * Since 6.15.0, `TransactionDB` returns error `Status`es from calls to `DeleteRange()` and calls to `Write()` where the `WriteBatch` contains a range deletion. Previously such operations may have succeeded while not providing the expected transactional guarantees. There are certain cases where range deletion can still be used on such DBs; see the API doc on `TransactionDB::DeleteRange()` for details. * `OptimisticTransactionDB` now returns error `Status`es from calls to `DeleteRange()` and calls to `Write()` where the `WriteBatch` contains a range deletion. Previously such operations may have succeeded while not providing the expected transactional guarantees. * Fix `WRITE_PREPARED`, `WRITE_UNPREPARED` TransactionDB `MultiGet()` may return uncommitted data with snapshot. +* In DB::OpenForReadOnly, if any error happens while checking Manifest file path, it was overridden by Status::NotFound. It has been fixed and now actual error is returned. ### Public API Change * Add new Append and PositionedAppend APIs to FileSystem to bring the data verification information (data checksum information) from upper layer (e.g., WritableFileWriter) to the storage layer. In this way, the customized FileSystem is able to verify the correctness of data being written to the storage on time. Add checksum_handoff_file_types to DBOptions. User can use this option to control which file types (Currently supported file tyes: kWALFile, kTableFile, kDescriptorFile.) should use the new Append and PositionedAppend APIs to handoff the verification information. Currently, RocksDB only use crc32c to calculate the checksum for write handoff.