-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
[BugFix] fix bug for sqlblacklist #44862
Conversation
Signed-off-by: before-Sunrise <[email protected]>
SqlBlackList.verifying(originSql); | ||
} | ||
} | ||
|
||
// Record planner costs in audit log | ||
Preconditions.checkNotNull(execPlan, "query must has a plan"); | ||
|
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.
The most risky bug in this code is:
SQL blacklist verification logic is duplicated, which can lead to unnecessary performance overhead and potential inconsistencies in SQL blacklist checking.
You can modify the code like this:
@@ -541,6 +541,19 @@ public void execute() throws Exception {
if (context.isHTTPQueryDump) {
return;
}
+ // For follower: verify sql in BlackList before forward to leader
+ // For leader: if this is a proxy sql, no need to verify sql in BlackList because every fe has its own blacklist
+ if (isQuery && Config.enable_sql_blacklist && !parsedStmt.isExplain() && !isProxy) {
+ OriginStatement origStmt = parsedStmt.getOrigStmt();
+ if (origStmt != null) {
+ String originSql = origStmt.originStmt.trim()
+ .toLowerCase().replaceAll(" +", " ");
+ // If this sql is in blacklist, show message.
+ SqlBlackList.verifying(originSql);
+ }
+ }
+
if (isForwardToLeader()) {
context.setIsForward(true);
forwardToLeader();
@@ -553,17 +566,6 @@ public void execute() throws Exception {
final boolean isStatisticsJob = AnalyzerUtils.isStatisticsJob(context, parsedStmt);
context.setStatisticsJob(isStatisticsJob);
- // This block is removed as it duplicates the blacklist check above
-
// Record planner costs in audit log
Preconditions.checkNotNull(execPlan, "query must has a plan");
By removing the duplicated block of SQL blacklist verification, we eliminate the redundancy, ensuring that the SQL blacklist check is done efficiently and only once per execution path.
Quality Gate passedIssues Measures |
[FE Incremental Coverage Report]✅ pass : 6 / 6 (100.00%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
@Mergifyio backport branch-3.3 |
@Mergifyio backport branch-3.2 |
@Mergifyio backport branch-3.1 |
✅ Backports have been created
|
@Mergifyio backport branch-3.0 |
@Mergifyio backport branch-2.5 |
✅ Backports have been created
|
✅ Backports have been created
|
✅ Backports have been created
|
✅ Backports have been created
|
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 3c881b0)
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 3c881b0)
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 3c881b0)
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 3c881b0) # Conflicts: # fe/fe-core/src/main/java/com/starrocks/qe/StmtExecutor.java
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 3c881b0) # Conflicts: # fe/fe-core/src/main/java/com/starrocks/qe/StmtExecutor.java
Signed-off-by: before-Sunrise <[email protected]>
…45020) Co-authored-by: before-Sunrise <[email protected]>
Signed-off-by: before-Sunrise <[email protected]>
Signed-off-by: before-Sunrise <[email protected]> (cherry picked from commit 58812e1)
…#45031) Co-authored-by: before-Sunrise <[email protected]>
Co-authored-by: before-Sunrise <[email protected]>
Why I'm doing:
Currently Follower FE will forward sql to Leader before verify blacklist, but every FE has its own blacklist, and this will cause two problems:
What I'm doing:
Fixes #issue
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: