danny0405 commented on code in PR #11580:
URL: https://github.com/apache/hudi/pull/11580#discussion_r1680182530
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/action/rollback/BaseRollbackPlanActionExecutor.java:
##########
@@ -113,6 +113,7 @@ protected Option<HoodieRollbackPlan> requestRollback(String
startRollbackTime) {
HoodieRollbackPlan rollbackPlan = new HoodieRollbackPlan(new
HoodieInstantInfo(instantToRollback.getTimestamp(),
instantToRollback.getAction()), rollbackRequests,
LATEST_ROLLBACK_PLAN_VERSION);
if (!skipTimelinePublish) {
+ table.validateForLatestTimestamp(rollbackInstant.getTimestamp());
Review Comment:
> Unfortunately (A) has the following drawbacks
Every operation must now hold the table lock when computing its plan even if
it's an expensive operation and will take a while
Users of HUDI cannot easily set their own instant time of an operation, and
this restriction would break any public APIs that allow this and would require
deprecating those APIs.
Even with these drawbacks, I still think A is the right fix, even if we
chech the requested instant is always the latest on the timeline, does not mean
that instant is following the `TrueTime`(monotonically increasing physically on
nodes), and there might still be a use case where the requested instant is the
latest but physically the instant happens ealier(because of the clock skew on
the machines).
Actually we already bring in completion time based compaction time
generation on master (a compaction plan only include files that are finished
earlier than the compaction instant), we should also do that for cleaning(and
this is the only problem that should fix on master).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
