Skip to content
Browse files

sstable: fix read failure of certain sstables

We had a problem reading certain existing Cassandra sstables into

Our consume_range_tombstone() function assumes that the start and end
columns have a certain "end of component" markers, and want to verify
that assumption. But because of bugs in older versions of Cassandra,
see, sometimes the
"end of component" was missing (set to 0). CASSANDRA-7593 suggested
this problem might exist on the start column, so we allowed for that,
but now we discovered a case where also the end column is set to 0 -
causing the test in consume_range_tombstone() to fail and the sstable
read to fail - causing Scylla to no be able to import that sstable from
Cassandra. Allowing for an 0 also on the end column made it possible
to read that sstable, compact it, and so on.

Fixes #1125.

Signed-off-by: Nadav Har'El <>
Message-Id: <>
(cherry picked from commit a05577c)
  • Loading branch information...
nyh authored and avikivity committed Mar 28, 2016
1 parent 3b5a55c commit 0b456578c09134ed178e022fec328dce316fb4fd
Showing with 1 addition and 1 deletion.
  1. +1 −1 sstables/
@@ -375,9 +375,9 @@ class mp_row_consumer : public row_consumer {
virtual void consume_range_tombstone(
bytes_view start_col, bytes_view end_col,
sstables::deletion_time deltime) override {
check_marker(end_col, composite_marker::end_range);
// Some versions of Cassandra will write a 0 to mark the start of the range.
// CASSANDRA-7593 discusses that.
check_marker(end_col, composite_marker::end_range, composite_marker::none);
check_marker(start_col, composite_marker::start_range, composite_marker::none);

// FIXME: CASSANDRA-6237 says support will be added to things like this.

0 comments on commit 0b45657

Please sign in to comment.
You can’t perform that action at this time.