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
<[email protected]> 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 <[email protected]>
> 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: [email protected]
For additional commands, e-mail: [email protected]
