[
https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878855#comment-17878855
]
Stefan Miklosovic commented on CASSANDRA-19448:
-----------------------------------------------
Can we just remove
{code:java}
precision=MICROSECONDS {code}
just like that? I am trying to figure out if it is not for something and us
removing it would break it. This is currently broken, yes, as a user can not
specify anything in greater granularity then seconds because it would be
ignored.
Tiago says:
_To support microsecond granularity, we need further changes in
`CommitLogReplayer` to accept microseconds instead of forcing comparison to be
in milliseconds._
I get that it is easier to just support the timestamp in microseconds
granularity and drop precision but ... is it {_}the right way to do that{_}?
If we have precision in micro then timestamp should support micros, if
precision is in millis, then timestamp should support millis etc. So based on
what precision we have, we would have corresponding formatter.
I am not sure if we should go with the way I just suggested but my gut feeling
is that precision was put there for these purposes, it is just broken /
unfinished. If we go to change the behavior, even removing a property which
seemingly does not do anything / it is broken, I think we should have it
confirmed that we are indeed going to drop precision field in the configuration
property.
If we do and we plan to put this into 4.x etc (into minors), I wonder if this
is not too much to ask. In that case we should probably keep precision around
and we should fix time formatters.
cc [~brandon.williams]
> CommitlogArchiver only has granularity to seconds for restore_point_in_time
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-19448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19448
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
> Reporter: Jeremy Hanna
> Assignee: Maxwell Guo
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Commitlog archiver allows users to backup commitlog files for the purpose of
> doing point in time restores. The [configuration
> file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties]
> gives an example of down to the seconds granularity but then asks what
> whether the timestamps are microseconds or milliseconds - defaulting to
> microseconds. Because the [CommitLogArchiver uses a second based date
> format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52],
> if a user specifies to restore at something at a lower granularity like
> milliseconds or microseconds, that means that the it will truncate everything
> after the second and restore to that second. So say you specify a
> restore_point_in_time like this:
> restore_point_in_time=2024:01:18 17:01:01.623392
> it will silently truncate everything after the 01 seconds. So effectively to
> the user, it is missing updates between 01 and 01.623392.
> This appears to be a bug in the intent. We should allow users to specify
> down to the millisecond or even microsecond level. If we allow them to
> specify down to microseconds for the restore point in time, then it may
> internally need to change from a long.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
