[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688862#comment-17688862
]
Berenguer Blasi commented on CASSANDRA-14227:
---------------------------------------------
Seems like downgradability, at the time of writing, is still being discussed
iiuc.
Now we're also writing an int, with the uint approach, and the sstable version
change is to signal a negative int being 'undefined data' vs 'a valid uint'.
Regardless of the downgradability discussion _I think_ (not tested) an sstable
scrub would suffice as scrub will either REJECT or CAP those entries. That is
pending the downgradibility discussion detailed requirements: forward
compatibility?, flag?, scrub?
Sthg to take into account though, thx for bringing it up.
> Extend maximum expiration date
> ------------------------------
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Reporter: Paulo Motta (Deprecated)
> Assignee: Berenguer Blasi
> Priority: Urgent
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
