[CASSANDRA-15292] Point-in-time recovery ignoring timestamp of static column updates

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.20, 3.11.6, 4.0-alpha3, 4.0
• Component/s: Local/Commit Log
• Bug Category: Correctness - Recoverable Corruption / Loss
• Severity: Normal
• Complexity: Low Hanging Fruit
• Discovered By: User Report
• Platform: All
• Since Version: 3.0 alpha 1

Source Control Link

https://github.com/apache/cassandra/commit/577a9e34f5ed28640c5abe4476f094c2ad2c51aa

Test and Documentation Plan

unit test

• Assignee: Unassigned
• Reporter: Vincent White

Authors

Vincent White

Reviewers

Michael Semb Wever

• Created: 26/Aug/19 02:36
• Updated: 15/May/20 08:53
• Resolved: 02/Jan/20 11:31

Description

During point-in-time recovery org.apache.cassandra.db.partitions.PartitionUpdate#maxTimestamp is checked to see if any write timestamps in the update exceed the recovery point. If any of the timestamps do exceed this point the the commit log replay is stopped.

Currently maxTimestamp only iterates over the regular rows in the update and doesn't check for any included updates to static columns. If a ParitionUpdate only contains updates to static columns then maxTimestamp will return Long.MIN_VALUE and always be replayed. 

This generally isn't much of an issue, except for non-dense compact storage tables which are implemented in the 3.x storage engine in large part with static columns. In this case the commit log will always continue applying updates to them past the recovery point until it hits an update to a different table with regular columns or reaches the end of the commit logs.

 

Patch
3.11
Trunk