[
https://issues.apache.org/jira/browse/CASSANDRA-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297043#comment-16297043
]
Alexander Dejanovski commented on CASSANDRA-8527:
-------------------------------------------------
[~rustyrazorblade], as much as I would like to count the range tombstones, my
understanding of the code shows that they are already merged with the rows
before being returned to the ReadCommand subclass in charge.
You can see here that this is done on purpose because the code path responsible
for reading a partition from memtables and sstables can be used from different
places (like compaction for example) :
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L563-L578
The way the code is architected, I don't see a way of returning the number of
range tombstones without pretty deep changes.
Counting the number of deleted rows is already very interesting and would not
require dangerous modifications.
Wether or not to count such rows in the failure threshold is clearly debatable
as it would indeed break existing (but probably poorly performing) queries.
But if we can't do this in a new major version, then when is the appropriate
time ?
A first step could be to introduce a flag and an additional warning.
It would be something like :
{noformat}
include_deleted_rows_in_tombstone_failure_threshold: false
{noformat}
If set to false (which would be the default at first) then we would issue a
warning that the query would probably fail in future versions or if the flag
was set to true.
If set to true, then the count of deleted rows would be summed to the tombstone
count to fail queries.
Then we could change this (or not) to false in future releases. I seem to
recall that an similar thing was done for cross_node_timeout and it is still
set to false by default to avoid timeouts when nodes aren't properly in sync on
time.
I've taken a look at how I could add unit tests for that code, and I would need
to hook on the table metrics of the ColumnFamilyStore object. The simplest way
of doing this without running the whole stack would be to use a Mockito spy.
Do you think adding Mockito to the list of dependencies is reasonable/wanted ?
> Account for range tombstones wherever we account for tombstones
> ---------------------------------------------------------------
>
> Key: CASSANDRA-8527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8527
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Alexander Dejanovski
> Fix For: 4.x
>
> Attachments: CASSANDRA-8527.diff
>
>
> As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds
> also apply to range tombstones, since they poses the same problems than cell
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
