Thanks for raising this. Agreed this is bad, when I filed CASSANDRA-14092 I thought a write would fail when localDeletionTime overflows (as it is with 2.1), but that doesn't seem to be the case on 3.0+
I propose adding the assertion back so writes will fail, and reduce the max TTL to something like 15 years for the time being while we figure a long term solution. 2018-01-25 18:05 GMT-02:00 Jeremiah D Jordan <jeremiah.jor...@gmail.com>: > If you aren’t getting an error, then I agree, that is very bad. Looking at > the 3.0 code it looks like the assertion checking for overflow was dropped > somewhere along the way, I had only been looking into 2.1 where you get an > assertion error that fails the query. > > -Jeremiah > >> On Jan 25, 2018, at 2:21 PM, Anuj Wadehra <anujw_2...@yahoo.co.in.INVALID> >> wrote: >> >> >> Hi Jeremiah, >> Validation is on TTL value not on (system_time+ TTL). You can test it with >> below example. Insert is successful, overflow happens silently and data is >> lost: >> create table test(name text primary key,age int); >> insert into test(name,age) values('test_20yrs',30) USING TTL 630720000; >> select * from test where name='test_20yrs'; >> >> name | age >> ------+----- >> >> (0 rows) >> >> insert into test(name,age) values('test_20yr_plus_1',30) USING TTL >> 630720001;InvalidRequest: Error from server: code=2200 [Invalid query] >> message="ttl is too large. requested (630720001) maximum (630720000)" >> ThanksAnuj >> On Friday 26 January 2018, 12:11:03 AM IST, J. D. Jordan >> <jeremiah.jor...@gmail.com> wrote: >> >> Where is the dataloss? Does the INSERT operation return successfully to the >> client in this case? From reading the linked issues it sounds like you get >> an error client side. >> >> -Jeremiah >> >>> On Jan 25, 2018, at 1:24 PM, Anuj Wadehra <anujw_2...@yahoo.co.in.INVALID> >>> wrote: >>> >>> Hi, >>> >>> For all those people who use MAX TTL=20 years for inserting/updating data >>> in production, https://issues.apache.org/jira/browse/CASSANDRA-14092 can >>> silently cause irrecoverable Data Loss. This seems like a certain TOP MOST >>> BLOCKER to me. I think the category of the JIRA must be raised to BLOCKER >>> from Major. Unfortunately, the JIRA is still "Unassigned" and no one seems >>> to be actively working on it. Just like any other critical vulnerability, >>> this vulnerability demands immediate attention from some very experienced >>> folks to bring out an Urgent Fast Track Patch for all currently Supported >>> Cassandra versions 2.1,2.2 and 3.x. As per my understanding of the JIRA >>> comments, the changes may not be that trivial for older releases. So, >>> community support on the patch is very much appreciated. >>> >>> Thanks >>> Anuj >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org