-
Notifications
You must be signed in to change notification settings - Fork 3.9k
[fix](mtmv) Clear stale partition state for prepared statements #66370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1443,6 +1443,22 @@ public Map<BaseTableInfo, Collection<Partition>> getMvCanRewritePartitionsMap() | |
| return mvCanRewritePartitionsMap; | ||
| } | ||
|
|
||
| /** Clear materialized-view planning state retained by a prepared statement between executions. */ | ||
| public void resetMaterializedViewStateForPreparedExecution() { | ||
| tableUsedPartitionNameMap.clear(); | ||
| commonTableIdToRelationIdToMap.clear(); | ||
| mvCanRewritePartitionsMap.clear(); | ||
| materializedViewRewriteDuration = 0; | ||
| hints.removeIf(UseMvHint.class::isInstance); | ||
| tmpPlanForMvRewrite.clear(); | ||
| rewrittenPlansByMv.clear(); | ||
| needPreMvRewriteRuleMasks.clear(); | ||
| needPreMvRewrite = false; | ||
| preMvRewritten = false; | ||
| materializationRewrittenSuccessSet.clear(); | ||
| relationIdToStatisticsMap.clear(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [P1] Clear retained MV candidates before rebuilding them A dropped MTMV can still be selected on the next execution: DROP marks the old object |
||
| } | ||
|
|
||
| public void setPrepareStage(boolean isPrepare) { | ||
| this.prepareStage = isPrepare; | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[P2] Remove retained MV hooks when rewrite is disabled
An enabled execution installs
InitMaterializationContextHook.INSTANCEin this reused context. If the session then disables MV rewrite,AddInitMaterializationHookmerely declines to add another hook; it does not remove the old one.containMaterializedViewHooktherefore remains true, soCollectRelationstill discovers MVs andlock()still acquires all retained MV-related table locks beforeinitMaterializationContextfinally rechecks the disabled flag. A writer holding any such lock can make a base-table EXECUTE wait for the one-minute planner timeout or fail even though MV rewrite is off. Remove only materialization hook instances here (preserving unrelated hooks) and clear their candidate/related-table state so the current collect pass can re-add them only when enabled.