cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime
Date Tue, 30 Jan 2018 20:19:00 GMT


Sam Tunnicliffe commented on CASSANDRA-14092:

bq. I think our default should be to cap with warnings.  What is a user going to do when they
get the error?  They are going to just go change there code to pick a new date that is still
real big, so I don't see a reason to fail things.

Yes, I imagine that's exactly what they will do, but the user will fully aware that it's happening,
not having their data changed on them. We ought to be being conservative by default here.

bq. We need a way to let users recover the data that was silently dropped.  I could see an
argument for a -D to let the data stay dropped, rather than recovering it, but I definitely
think our default here should be to recover the lost data.

I don't agree. It's definitely bad that the data was silently dropped, but like I said we
(the db) has no way of knowing what (application) decisions have been taken based on the visible
state of the database. I think it's pretty clear that if the data appeared to be gone at any
point (and we have no good reason to assume that the client has not observed such a state)
that it must stay gone. 

bq. Does this actually happen?

Yes, of course I tested it.

> Max ttl of 20 years will overflow localDeletionTime
> ---------------------------------------------------
>                 Key: CASSANDRA-14092
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Paulo Motta
>            Assignee: Paulo Motta
>            Priority: Blocker
>             Fix For: 2.1.20, 2.2.12, 3.0.16, 3.11.2
> CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 2038 overflow
bug|] for {{localDeletionTime}}.
> It turns out that next year the {{localDeletionTime}} will start overflowing with the
maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 years) > Integer.MAX_VALUE}}),
so we should remove this limitation.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message