New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compaction causes previously deleted value to reappear #184
Comments
Comment #1 originally posted by kevin.d.regan on 2013-06-13T01:16:23.000Z: This seems to be related to the size of the database. Reducing the number of keys to 1000000 causes the example to work correctly. Conversely, increasing the value size for each entries causes the required number of keys necessary to trigger the error to go down. |
Comment #2 originally posted by kevin.d.regan on 2013-06-13T01:18:54.000Z: Also, the overlap of keys was necessary to trigger the error (if I move the range 1 keys to a non-overlapping prefix, the problem went away). |
Comment #3 originally posted by kevin.d.regan on 2013-06-13T01:19:39.000Z: Expected output should be: Creating first key range |
Comment #4 originally posted by sanjay@google.com on 2013-06-13T19:32:35.000Z: I have reproduced the problem and have a fix in progress. A new release should be out soon. |
Comment #5 originally posted by dgrogan@chromium.org on 2013-06-13T23:30:35.000Z: Fixed in 1.11.0. |
Format json in README.md
LevelDB up to version 1.11 contained a bug [1] that sometimes could make previously deleted keys reappear after compaction. We should upgrade our bundled LevelDB to a more recent version to benefit from bug fixes in it. However, version 1.14 introduced a change that made rolling back to a previous LevelDB version harder. See AURORA-21661 for details. So for now we upgrade to the most recent version that is fully backwards compatible. [1] google/leveldb#184 Conflicts: support/mesos-tidy/entrypoint.sh
LevelDB up to version 1.11 contained a bug [1] that sometimes could make previously deleted keys reappear after compaction. We should upgrade our bundled LevelDB to a more recent version to benefit from bug fixes in it. However, version 1.14 introduced a change that made rolling back to a previous LevelDB version harder. See AURORA-21661 for details. So for now we upgrade to the most recent version that is fully backwards compatible. [1] google/leveldb#184 Conflicts: support/mesos-tidy/entrypoint.sh
Original issue 178 created by kevin.d.regan on 2013-06-13T01:12:41.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The expected output from the program is:
Creating first key range
Creating second key range
Deleting second key range
Compacting database
Counting number of keys left
Found 0 keys
The actual output is:
Creating first key range
Creating second key range
Deleting second key range
Compacting database
Counting number of keys left
Found 1222706 keys
What version of the product are you using? On what operating system?
1.9, 1.10
FreeBSD, Ubuntu 12.10
Please provide any additional information below.
include <iostream>
include <sstream>
include <cstdlib>
include <leveldb/db.h>
include <leveldb/write_batch.h>
namespace {
const std::string DB_PATH = "/tmp/my_test_db";
size_t NUM_KEYS = 1100000;
void
check_status(const leveldb::Status& status, const std::string& error_msg)
{
if (!status.ok()) {
std::cerr << "ERROR: " << error_msg << ": " <<
status.ToString() << std::endl;
std::exit(1);
}
}
std::string
create_key_1(size_t i)
{
std::ostringstream out;
out << "my_key_" << i;
return out.str();
}
std::string
create_key_2(size_t i)
{
return create_key_1(i) + "_xxx";
}
} // namespace
int
main (int argc, char** argv)
{
// open database
leveldb::DB* db;
leveldb::Options db_options;
db_options.create_if_missing = true;
leveldb::Status status = leveldb::DB::Open(db_options, DB_PATH, &db);
check_status(status, "Could not open database");
}
The text was updated successfully, but these errors were encountered: