-
Notifications
You must be signed in to change notification settings - Fork 603
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
test: support background_ddl_rate
in recovery test
#13552
Conversation
d45042c
to
73830ae
Compare
d1e2c09
to
43e25e7
Compare
21e8b0d
to
54e9d7d
Compare
background_ddl_rate
in recovery test
bail!("failed to query pg_matviews for {mview_name}"); | ||
}; | ||
|
||
match result[0].try_get::<_, i64>(0) { |
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.
/// Set background ddl | ||
SetBackgroundDdl { | ||
enable: bool, | ||
}, |
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.
As SET will be replayed after recovery, is it okay to directly fetch the value of background_ddl with SQL?
If we have Cmd::SetBackgroundDdl
, we can use it to check if background_ddl_rate
is set along with manually setting SET BACKGROUND_DDL
.
Both of these are incompatible, since background_ddl_rate
can randomly SET BACKGROUND_DDL
, and make the result of the test with SET BACKGROUND_DDL
unexpected.
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.
IMO it's not much effort to parse it.
let sql = sql.to_lowercase(); | ||
let tokens = sql.split_whitespace(); | ||
let mut tokens = tokens.multipeek(); | ||
let first_token = tokens.next().unwrap_or(""); |
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.
If we have some tests intended to fail with parse error, will this lead to panic of the test driver?
Removed the unwraps
.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #13552 +/- ##
==========================================
+ Coverage 68.22% 68.24% +0.02%
==========================================
Files 1521 1521
Lines 261709 261719 +10
==========================================
+ Hits 178557 178617 +60
+ Misses 83152 83102 -50
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Hi, PTAL @BugenZhao @yezizp2012 |
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.
Rest LGTM
"set" => { | ||
if sql.contains("background_ddl") { | ||
let enable = sql.contains("true"); | ||
SqlCmd::SetBackgroundDdl { enable } | ||
} else { | ||
SqlCmd::Others | ||
} | ||
} |
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.
Will this be too hard-coded?
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.
Alternative is to use frontend to do parsing for each statement. But I choose not to do it because it may cause regression in our test runtime. So I think this is good enough for testing purpose.
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 functionality LGTM, but I'm not sure if it's a good practice to change the create way of every mview in each slt by chance. Previously adding kill-rate
in recovery test was to reduce the total test time in CI test, it's more like a operation action for recovery test. The background_ddl_rate
somehow changes the test cases I think, what if user want to run some tests in foreground on purpose?
I think maybe background_ddl tests is enough and already involved in recovery test to see if it's recoverable. And we can add some more tests under background_ddl
and integration tests. 🤔
I agree that user may want to run some tests in foreground on purpose, and test recovery for it. This test managed to catch several bugs and I would prefer to keep it since it includes more coverage, that would take a long time to add manually. |
let next = *tokens.peek()?; | ||
if "if" == next | ||
&& let Some("not") = tokens.peek().cloned() | ||
&& let Some("exists") = tokens.peek().cloned() { |
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.
Oh, it's multipeek
. 🥵 Confused me at the first glance.
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.
LGTM
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
StreamValues
,DeltaJoin
.WAIT
, and making sure it is created by querying the mview catalog.BACKGROUND_DDL
variable.Checklist
./risedev check
(or alias,./risedev c
)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.