Andy Tolbert created CASSANDRA-11068:
----------------------------------------
Summary: Entire row is compacted away if remaining cells are
tombstones expiring after gc_grace_seconds
Key: CASSANDRA-11068
URL: https://issues.apache.org/jira/browse/CASSANDRA-11068
Project: Cassandra
Issue Type: Bug
Reporter: Andy Tolbert
Assuming the following schema:
{code}
CREATE TABLE simple.data (
k text PRIMARY KEY,
v int
) WITH gc_grace_seconds = 300;
{code}
And the following queries:
{code}
insert into simple.data (k, v) values ('blah', 1);
delete reading from simple.data where k='blah';
{code}
Performing a {{select *}} from this table will return 1 row with a null value:
{code}
cqlsh> select * from simple.data;
k | v
-----------+---------
blah | null
{code}
Prior the 3.0, if I were to do a flush, the sstable representation of this
table would include an empty cell and a tombstone:
{code}
[
{"key": "blah",
"cells": [["","",1453747038457027],
["v",1453747112,1453747112383096,"d"]]}
]
{code}
As my gc_grace_seconds value is 300, if I wait 5 minutes and perform a
compaction, the new sstable would omit the tombstone, but the empty cell would
still be present:
{code}
[
{"key": "blah",
"cells": [["","",1453747038457027]]}
]
{code}
Performing the {{select *}} query would still yield the same result because of
this.
However, in 3.2.1 this does not seem to be the behavior, after deleting the 'v'
cell, performing a flush and then waiting 5 minutes and doing a compact, what
ends up happening is that the sstable completely disappears (presumably because
there is no remaining data) and the select query emits 0 rows:
{code}
cqlsh> select * from simple.data;
k | v
-----------+---------
(0 rows)
{code}
I'm unsure if this is by design or a bug, but it does represent a change
between C* versions.
I have not tried this for a table with clustering columns yet, but I assume
that the behavior will be the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
