Skip to content

branch-4.1: [fix](mtmv) Avoid mutating excluded trigger tables (#62984)#64519

Open
seawinde wants to merge 1 commit into
apache:branch-4.1from
seawinde:pr_62984_to_branch-4.1
Open

branch-4.1: [fix](mtmv) Avoid mutating excluded trigger tables (#62984)#64519
seawinde wants to merge 1 commit into
apache:branch-4.1from
seawinde:pr_62984_to_branch-4.1

Conversation

@seawinde

Copy link
Copy Markdown
Member

pr: #62984
commitId: 464d89c

Backport #62984 to branch-4.1.

This fixes isMTMVPartitionSync mutating caller-owned excluded trigger table sets. The backport adapts the upstream TableNameInfo change to branch-4.1, which still uses TableName in this code path, by copying the input set into a local mutable Set before adding followed PCT tables.

Conflict resolution:

  • fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVPartitionUtil.java: kept branch-4.1 TableName API and applied the local-copy behavior.
  • fe/fe-core/src/test/java/org/apache/doris/mtmv/MTMVPartitionUtilTest.java: adapted the upstream immutable-set test to branch-4.1 JMockit style and TableName type.

Tests:

  • git diff --check upstream/branch-4.1..HEAD
  • ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVPartitionUtilTest

Problem Summary:

isMTMVPartitionSync adds followed PCT tables into the excluded trigger
table set while checking partition sync. Some callers pass immutable
sets, such as the force-consistent rewrite path using ImmutableSet.of(),
so partitioned MTMVs can fail with UnsupportedOperationException before
the sync check finishes. Copy the input set into a local mutable set
before adding derived PCT tables, avoiding mutation of caller-owned
state and supporting immutable inputs.

---------

Co-authored-by: yangtao555 <yangtao555@jd.com>
@seawinde seawinde requested a review from yiguolei as a code owner June 15, 2026 07:55
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@seawinde

Copy link
Copy Markdown
Member Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 50.00% (1/2) 🎉
Increment coverage report
Complete coverage report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants