-
Notifications
You must be signed in to change notification settings - Fork 590
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
feat(session_config): system wide session config by alter system set #16062
Conversation
Is this PR ready for review? |
type Err = &'static str; | ||
|
||
fn from_str(_s: &str) -> Result<Self, Self::Err> { | ||
bail_not_implemented!(issue = 10736, "isolation level"); | ||
fn from_str(s: &str) -> Result<Self, Self::Err> { | ||
match s { |
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.
Simply bail will cause deserialization fail
// FIXME: use a real reporter | ||
let reporter = &mut (); |
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.
@TennyZhuang do we need to report this when alter system?
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.
Is it possible for a session variable to be entirely unconfigured?
Consider some session variable A.
- User did not set
A
. - User did not set default for
A
system wide either.
Then I suppose it will fallback to the default we wrote for it in the code?
Is it possible for session variables to be None
by default after this PR?
No. You can check the |
@@ -593,6 +593,27 @@ service SystemParamsService { | |||
rpc SetSystemParam(SetSystemParamRequest) returns (SetSystemParamResponse); | |||
} | |||
|
|||
message GetSessionParamsRequest {} |
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.
Can we first unify the terms? Or is there any difference between "session config" and "session param"?
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.
I tried to use session config in frontend. But I guess it's ok to just use session params everywhere
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.
But let me rename it in the next pr.
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.
Hmmm, why renaming in next
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.
You probably won't want to review 200 lines of rename in this pr...
/// Show all parameters except those specified `NO_SHOW_ALL`. | ||
pub fn show_all(&self) -> Vec<VariableInfo> { | ||
vec![ | ||
#(#show_all_list)* | ||
] | ||
} | ||
|
||
/// List all parameters | ||
pub fn list_all(&self) -> Vec<VariableInfo> { |
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 difference of these two methods is subtle. Is NO_SHOW_ALL
essentially hidden
? 😄
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.
BTW, which set of parameters should be attributed with NO_SHOW_ALL
and why do they need this? Is there any documentation from Postgres that we can refer to?
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.
fn from_str(_s: &str) -> Result<Self, Self::Err> { | ||
bail_not_implemented!(issue = 10736, "isolation level"); | ||
fn from_str(s: &str) -> Result<Self, Self::Err> { | ||
match s { |
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.
Should ignore the case.
src/frontend/src/session.rs
Outdated
))); | ||
} | ||
}; | ||
let session_config = self.env.meta_client().get_session_params().await?; |
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.
This looks bad. Should we adopt the notification/subscription mechanism just like the catalogs?
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.
Maybe it is enough to only load the config when the frontend starts for now?
https://www.postgresql.org/docs/current/sql-altersystem.html
Values set with ALTER SYSTEM will be effective after the next server configuration reload, or after the next server restart in the case of parameters that can only be changed at server start. A server configuration reload can be commanded by calling the SQL function pg_reload_conf(), running pg_ctl reload, or sending a SIGHUP signal to the main server process.
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 reload behavior of different config depends on its context
value, according to https://www.postgresql.org/docs/current/view-pg-settings.html. We may verify the behavior for calling ALTER SYSTEM
on these session configs in Postgres and provide a precise definition then.
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.
We have no plan to support config file for session parameters cc @fuyufjh
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.
We have no plan to support config file for session parameters
Yes. Different from PG, RW is distributed, which naturally makes config file different from the system params. I'd like to consider them as non-overlapped sets (except state store's initial config, which is the only exception)
See also https://github.com/risingwavelabs/rfcs/blob/main/rfcs/0034-system-parameters.md
Please add some e2e tests to demonstrate the behavior. |
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 approach in this PR is acceptable to me, but it seems far away from the thing you folks discussed before - that is, unifying the session params and global params.
The rest LGTM.
src/common/src/session_config/mod.rs
Outdated
/// If `RW_IMPLICIT_FLUSH` is on, then every INSERT/UPDATE/DELETE statement will block | ||
/// until the entire dataflow is refreshed. In other words, every related table & MV will | ||
/// be able to see the write. | ||
#[serde(rename = "rw_implicit_flush")] | ||
#[parameter(default = false, rename = "rw_implicit_flush")] | ||
implicit_flush: 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.
2 renames here 😄. How about just renaming the field to rw_implicit_flush
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.
Rename this will cause too many unrelated changes to this pr. Maybe later.
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!
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
|
||
|
||
statement error | ||
set transaction_isolation to 'read committed'; |
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.
This case is for testing the error ui for setting an invalid value to a session variable. If you find this not applicable to transaction_isolation
, please replace it with another session variable instead of simply removing it.
serde_json::from_str(&self.0.get_session_params().await?) | ||
.context("failed to parse session config")?; |
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.
This essentially introduces compatibility issue for session variables. Please document it somewhere and consider covering it with backwards-compat tests.
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.
This will not have compatibility issue as long as the meta and front version are the same
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.
You're right. JSON is only used as an intermediate representation.
However, we still persist the keys and values. Prior to this PR, we avoid breaking the session variables (like names or value types) only with best effort to provide SQL-level compatibility. After this PR, however, we must be more careful about that. 😕
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.
I guess this is also true for many other things we persisted. For session params if we want to change the name, we can provide a persist key name
.
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Allow set a system-wide session config by
alter system set xxx to yyy
The session config will be initiated in every new session using the system-wide session config
Checklist
./risedev check
(or alias,./risedev c
)Documentation
You can set a system-wide default value for a session parameter, from which parameters in a new session will be initialized.
alter system set session_param_name to session_param_value
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.