The behaviour of GetUpdatesSince is not the same as documented

[bluesalt]

Here is the document of the API

  // Sets iter to an iterator that is positioned at a write-batch containing
  // seq_number. If the sequence number is non existent, it returns an iterator
  // at the first available seq_no after the requested seq_no
  // Returns Status::OK if iterator is valid
  // Must set WAL_ttl_seconds or WAL_size_limit_MB to large values to
  // use this api, else the WAL files will get
  // cleared aggressively and the iterator might keep getting invalid before
  // an update is read.
  virtual Status GetUpdatesSince(
      SequenceNumber seq_number, unique_ptr<TransactionLogIterator>* iter,
      const TransactionLogIterator::ReadOptions&
          read_options = TransactionLogIterator::ReadOptions()) = 0;

It is clear that the iterator should be after the requested seq_no if the requested seq_no is not existing. I have a db which currently holds two sequence number 1, 4. However, the following programming emits

1
4

Per the document, only 4 should be emitted. Do I misunderstand the doc ?

Here is the program:

#include <iostream>
#include "rocksdb/db.h"

using namespace std;

int main() {
    rocksdb::DB* db;
    rocksdb::Options options;
    rocksdb::Status status = rocksdb::DB::OpenForReadOnly(options, "/tmp/kv", &db);

    unique_ptr<rocksdb::TransactionLogIterator> iter;
    status = db->GetUpdatesSince(2, &iter);
    rocksdb::WriteBatch wb;
    if (status.ok()) {
        for (; iter->Valid(); iter->Next()) {
            auto batch_result = iter->GetBatch();

            wb = *batch_result.writeBatchPtr;
            cout << batch_result.sequence << endl;
        }
    }

    delete db;

    return 0;
}

[markk12]

i m interested in it , but i dont understand how to read data .batch_result is batch class for executing a batch not for read what i executed before. I might to find i put the key X and value Y for example. And then if i work with columns how to do?

[riversand963]

@bluesalt yeah, it is possible that the requested seq meets the following conditions:

batch_start_seq <= seq <= batch_end_seq

while the TransactionLogIterator::GetBatch() just returns the batch_start_seq. Therefore, you will find that the first seq of GetBatch() is smaller than seq.

Proposed a fix in #9355