[
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700069#comment-14700069
]
Aleksey Yeschenko commented on CASSANDRA-9917:
----------------------------------------------
bq. True, but let me clarify: if no node in the cluster is down for longer than
max hint window, and you have no hardware failures, and you have batch
commitlog enabled, then you won't need repair. Fair?
I might be misunderstanding the context, but no, in general this is not true. A
request times out, a hint - or a batchlog entry gets written - a table in the
mutation has a low gc gs - the batchlog/hint entry expires before it can be
replayed, and we now need repair.
bq. Especially since Paulo independently came up with the same value we use as
default max hint window here.
Right. Independently.
> MVs should validate gc grace seconds on the tables involved
> -----------------------------------------------------------
>
> Key: CASSANDRA-9917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9917
> Project: Cassandra
> Issue Type: Bug
> Reporter: Aleksey Yeschenko
> Assignee: Paulo Motta
> Labels: materializedviews
> Fix For: 3.0 beta 2
>
>
> For correctness reasons (potential resurrection of dropped values), batchlog
> entries are TTLs with the lowest gc grace second of all the tables involved
> in a batch.
> It means that if gc gs is set to 0 in one of the tables, the batchlog entry
> will be dead on arrival, and never replayed.
> We should probably warn against such LOGGED writes taking place, in general,
> but for MVs, we must validate that gc gs on the base table (and on the MV
> table, if we should allow altering gc gs there at all), is never set too low,
> or else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
