TheR1sing3un commented on code in PR #13606:
URL: https://github.com/apache/hudi/pull/13606#discussion_r2229859367
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/timeline/versioning/v2/TimelineArchiverV2.java:
##########
@@ -256,6 +260,25 @@ private List<HoodieInstant> getCommitInstantsToArchive()
throws IOException {
earliestInstantToRetainCandidates.add(qualifiedEarliestInstant);
}
+ // 6. If archival should consider `earliest retain instant` in the clean
plan,
+ // we should add the earliest retain instant from the clean plan to the
candidates.
+ if (config.shouldArchiveKeepCleanPlanRetainInstant()) {
Review Comment:
> I don't think the cleaning progress should blocking the archiving in
general.
However, in fact, the current archival has been directly or indirectly
affected by cleaning. For example, the number of commits that archival needs to
retain needs to be adjusted according to the cleaning strategy, and the first
replace commit after the `retain instant` retained by cleaning needs to be
considered.
Or could we solve my core problem in another way: not wanting the
incremental partition scanning in cleaning to always fall back to full table
scanning. At present, the main reason for the fallback is that the `retain
instant` was archived. Do you have any better ideas?
--
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]
