[
https://issues.apache.org/jira/browse/CASSANDRA-15882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thanh updated CASSANDRA-15882:
------------------------------
Resolution: Invalid
Status: Resolved (was: Triage Needed)
> sstablemetadata should show tombstone timestamp not just the local drop time
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-15882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15882
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Thanh
> Priority: Normal
>
> issue/request:
> sstablemetadata should show tombstone timestamp not just the local drop time
>
> I'm not sure what all versions this exists in but the sstablemetadata
> tombstone "drop time" only just shows the local delete time of the
> tombstones. What's more important (what the tombstone expiration time
> depends on) is the tombstone writetime (tombstone timestamp). It's possible
> to, and a surprising number of users have done this, write a tombstone with a
> timetamp in the future (by doing "DELETE...USING TIMESTAMP
> <future_timestamp>"). When this happens, the tombstone hangs around in
> sstables for a lot longer than users expect because
> {code:java}
> tombstone_expiration_time = gc_grace_seconds + tombstone_timestamp{code}
> NOT
> {code:java}
> tombstone_expiration_time = gc_grace_seconds +
> tombstone_local_delete_time{code}
> and the sstablemetadata output doesn't help here because it only shows the
> local delete time, not the actual tombstone timestamp that's used to
> calculate tombstone expiration time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
