github-actions[bot] commented on code in PR #68180:
URL: https://github.com/apache/doris/pull/68180#discussion_r4045544587


##########
fe/fe-core/src/main/java/org/apache/doris/catalog/MTMV.java:
##########
@@ -616,26 +622,39 @@ public void invalidateIvmBaseline() {
         editLogItem.await();
     }
 
+    /**
+     * Mark the MV partitions that may hold rows read from the changed base 
table partitions as needing a
+     * rebuild. When those partitions cannot be determined, the whole MV is 
marked instead.
+     */
     public void invalidateIvmBaseline(BaseTableInfo baseTableInfo, Map<String, 
Long> changedPartitions) {
+        // Computed before the MV lock is taken, not inside it: the mapping 
reads the partition items of the
+        // MV and of every PCT table, so it takes those tables' locks, and the 
MV lock has to stay a leaf
+        // (nothing may be acquired under it) the way the rest of this class 
assumes. The selection does not
+        // need to be atomic with the barrier it produces: the barrier is 
recorded under the lock below, and
+        // the names it carries are intersected with the live partition names 
when they are consumed
+        // (MTMVTask).
+        Optional<Set<String>> affectedMvPartitions = 
selectAffectedMvPartitions(baseTableInfo,
+                changedPartitions);
+        if (affectedMvPartitions.isPresent() && 
affectedMvPartitions.get().isEmpty()) {
+            // No MV partition reads any of the changed base partitions, so 
this change cannot leave
+            // anything behind here: there is no barrier to persist, and 
skipping the version bump
+            // keeps it from discarding the result of a task that is already 
running.
+            LOG.debug("No MV partition is affected by changed base partitions, 
mv={}, baseTable={}, "
+                    + "changedPartitions={}", name, baseTableInfo, 
changedPartitions);

Review Comment:
   The empty result is not safe with `partition_sync_limit` plus EXPR roll-ups. 
If an MV month partition already contains an expired old day and a newer day in 
the same month, the generator filters the old day before roll-up, so this 
mapping reports only the newer day and the fast path returns without a baseline 
barrier. Dropping, truncating, or replacing the old base partition then emits 
no row binlog, while partition sync retains the month partition via the newer 
day, leaving the old rows permanently stale. Please derive the affected set 
from lineage independent of the current sync-limit filter, or conservatively 
invalidate the retained roll-up partition when a changed base partition is 
excluded from this mapping.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to