I think what was meant by this A timestamp (typically in microseconds since the unix epoch, although this is not enforced)
is that the timestamp can be a "logical" timestamp from some source where the clock just "ticks" from 0 etc ... It does not mean that we could once put there milliseconds, another time it would save it in microseconds etc. Is this correct interpretation? On Tue, Sep 3, 2024 at 2:48 PM Štefan Miklošovič <smikloso...@apache.org> wrote: > commitlog_archiving.properties contains a property called "precision" > which is by default set to MICROSECONDS (1). However, we have this > formatter for restore_point_in_time (2). The restoration time will ever be > evaluated to milliseconds here (3) and it loses anything beyond seconds. > When restore time is e.g. 2012:04:31 20:43:12.123, the formatter will > remove .123 and that is converted to milliseconds via .getTime(). Then it > goes here (4), it will convert maxTimestamp() to milliseconds and compare > it to restoreTarget which is in milliseconds too but we dropped the > milliseconds resolution because of the formatter. > > CASSANDRA-19448 tries to solve this by removing precision property and > supporting resolutions in restore_point_in_time down to microseconds but I > am not sure we can remove it just like that. Can we? > > What confuses me is the comment here: > > # precision of the timestamp used in the inserts (MILLISECONDS, > MICROSECONDS, ...) > precision=MICROSECONDS > > _used in the inserts_ ? What does it mean exactly? For example, when we > use USING TIMESTAMP, isn't that in microseconds already? > > It looks like it was (or it is?) possible to insert into Cassandra with > different resolutions so this property was introduced to match what > resolution we were writing the inserts with internally? > > If maxTimestamp() on PartitionUpdate (4) is ever going to return > resolution in microseconds, we can get rid of that, but if it ever returns > something else (like in milliseconds), we can not, right? (without > reflecting that in precision). Under what circumstances it would be > returned in anything but in microseconds? > > PartitionUpdate.maxTimestamp() contains e.g. > > long maxTimestamp = deletionInfo.maxTimestamp(); > > That calls > > partitionDeletion.markedForDeleteAt() > > where its Javadoc says (5) - "A timestamp (typically in microseconds since > the unix epoch, although this is not enforced)". > > Is this still relevant 5.x times? > > (1) > https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties#L57 > (2) > https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties#L40 > (3) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L128 > (4) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L498 > (5) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionTime.java#L82-L86 >
