[
https://issues.apache.org/jira/browse/CASSANDRA-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164032#comment-14164032
]
Takenori Sato commented on CASSANDRA-8038:
------------------------------------------
{quote}
If you don't care about read-repair (because repair is running regularly), why
don't you just disable read-repair altogether? I'm not convinced that "I want
read-repair but not for tombstone" is useful enough in general that it's worth
adding an option.
{quote}
Even if read repair is disabled, at least (R-1) requests are made, on which
node tombstones are read into memory. So I don't see it can solve the problem.
Also, I understand read repair is the only reason why tombstones have to be
kept in memory(both for data and digest requests), and sent back to a
coordinator(if it is a data request), though only live columns are returned to
a client. Am I right?
{quote}
Further, it looks like the patch actually skips tombstones from
ArrayBackedSortedColumns.maybeAppendColumn which means that tombstone will be
skipped on every read, not just on read-repair. Doing so is definitively wrong
since the tombstone might delete data on some other replica upon reconciliation
on the coordinator.
{quote}
Yes, I intended to do so. I wasn't aware of such a possibility, "tombstone
might delete data on some other replica upon reconciliation on the coordinator".
Can you explain how it could happen? Also, let me know if a relevant test case
exists. I will add such a test case, and reconsider the design.
> A new config option to ignore column tombstones for RR or not
> -------------------------------------------------------------
>
> Key: CASSANDRA-8038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8038
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Takenori Sato
> Fix For: 2.1.1
>
> Attachments: CASSANDRA-8038-v2.txt, CASSANDRA-8038-v3.txt,
> CASSANDRA-8038.txt
>
>
> CASSANDRA-6117 addressed the death of Cassandra by column tombstones, and
> whose fix was to raise an error when reading more tombstones than a
> threshold. I think it is an emergency action, rather than a fix.
> We have had this issue for long. So I wondered, in the first place, if it is
> really necessary to collect non-gc-able tombstones, which could cause
> concurrent mode failures, and OOM eventually?
> Actually, I was surprised by the fact that Cassandra takes them into
> consideration. Rather, I prefer to raise a threshold, and tell Cassandra to
> ignore tombstones for digest calculation of RR because a repair is running
> regularly.
> I guess there are some people like me, but not all. So what about adding a
> new configuration option if Cassandra ignores column tombstones for RR or not?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
