[ https://issues.apache.org/jira/browse/CASSANDRA-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351979#comment-16351979 ]
Kurt Greaves edited comment on CASSANDRA-14092 at 2/5/18 2:09 AM: ------------------------------------------------------------------ bq. Do you mind proof-reading the NEWS.txt and check if something is not clear/can be improved? Thanks! Looks good, but a few things to reduce confusion: # Can we stick a PLEASE READ/WARNING/ALERT or something in the title to make it clear that users actually have to read that section? Can we be a bit more clear on the following points? # Expired records due to overflow *will* be removed permanently after a compaction. (there's only a very small chance that it would survive a compaction, and that's only if they previously wrote the same record and it overflowed by more, which somehow made it into a separate SSTable and didn't get compacted with ) # Data that is expired due to overflow *will* not be queryable and that prior to patching they'll have no way of telling they inserted with an overflowed TTL. # How to search for negative min local deletion times (sstablemetadata) # Probably a good time to note that all users will need to upgrade to >4.0 by 2038 and that during upgrade their TTL's will be set to their expected value. was (Author: kurtg): .bq Do you mind proof-reading the NEWS.txt and check if something is not clear/can be improved? Thanks! Looks good, but a few things to reduce confusion: # Can we stick a PLEASE READ/WARNING/ALERT or something in the title to make it clear that users actually have to read that section? Can we be a bit more clear on the following points? # Expired records due to overflow *will* be removed permanently after a compaction. (there's only a very small chance that it would survive a compaction, and that's only if they previously wrote the same record and it overflowed by more, which somehow made it into a separate SSTable and didn't get compacted with ) # Data that is expired due to overflow *will* not be queryable and that prior to patching they'll have no way of telling they inserted with an overflowed TTL. # How to search for negative min local deletion times (sstablemetadata) # Probably a good time to note that all users will need to upgrade to >4.0 by 2038 and that during upgrade their TTL's will be set to their expected value. > Max ttl of 20 years will overflow localDeletionTime > --------------------------------------------------- > > Key: CASSANDRA-14092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14092 > 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|https://en.wikipedia.org/wiki/Year_2038_problem] 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org