[
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706807#comment-14706807
]
Aleksey Yeschenko commented on CASSANDRA-9917:
----------------------------------------------
Yep, this is it. Can almost commit as is.
Pushed some minor tweaking
[here|https://github.com/iamaleksey/cassandra/commit/d9a951e13a1ac5f3fc80cfc399ebadbf7701f2d3]
to make the language slightly less verbose and also avoid allocating a hashset
in the common case of no tables having a gc gs of 0. This is going to require
updating dtests a bit.
I want one more thing addressed, though. Logging in {{BatchStatement}} needs to
be changed. For one, we definitely should not log a warning for each table. It
should be once per batch. Secondly, it should be rate-limited (use
{{NoSpamLogger}}). Thirdly, it should utilize the now available client warning
facility ({{ClientWarn}}).
You should look at how this is handled by {{verifyBatchType}}.
> 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: docs-impacting, 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)
