-
Notifications
You must be signed in to change notification settings - Fork 3.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
settings: make .Override
set the value origin
#111150
Conversation
In a later commit, we will want to ensure that `.Override()` sets the modified bit. This is not possible if the modified bits are in the Updater. (The `Override` method is on the setting itself and has no access to the updater.) Release note: None
This commit simplifies the Updater interface as follows: - it provides a new `SetFromStorage()` method which combines the effect of `Set()` and `SetValueOrigin()` into one method. The settings watcher is also modified to use this new method. - it provides a new `SetToDefault()` method which resets a setting to its registered default. This is then used instead of `Set(s.EncodedDefault())` in the setting watcher. The benefit here is that `SetToDefault()` properly clears the 'modified' bit, which we plan to use in a later commit. Release note: None
This commit uses the "value origin" field now throughout to decide whether or not a setting was modified. Release note: None
Prior to this patch, setting overrides in tests did not have their value origin set properly. This patch fixes it. Release note: None
a373c2f
to
dc36146
Compare
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.
Reviewed 6 of 6 files at r4, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @knz)
-- commits
line 39 at r4:
nit: should we add a unit test for this?
TFYRs! bors r=yuzefovich,stevendanna |
Build succeeded: |
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.
Reviewable status: complete! 1 of 0 LGTMs obtained
Previously, yuzefovich (Yahor Yuzefovich) wrote…
nit: should we add a unit test for this?
I will do so in #111153.
111153: settings: simple refactors r=yuzefovich,stevendanna a=knz See the last 7 commits for details. Previous in sequence: - [x] #110789 and #110947 - [x] #110676 - [x] #111008 - [x] #111145 - [x] #111147 - [x] #111149 - [x] #111150 Needed for #110758 Epic: CRDB-6671 Co-authored-by: Raphael 'kena' Poss <[email protected]>
110758: server,settings: properly cascade defaults for TenantReadOnly r=stevendanna,yuzefovich a=knz Previous in sequence: - [x] #110789 and #110947 - [x] #110676 - [x] #111008 - [x] #111145 - [x] #111147 - [x] #111149 - [x] #111150 - [x] #111153 - [x] #111475 - [x] #111210 - [x] #111212 Fixes #108677. Fixes #85729. Fixes #91825. Completes the work described in the settings RFC. Epic: CRDB-6671 TLDR: this patch ensures that virtual cluster servers observe changes made to TenantReadOnly settings via SET CLUSTER SETTING in the system interface, even when there is no override set via ALTER VIRTUAL CLUSTER SET CLUSTER SETTING. For example, after `SET CLUSTER SETTING kv.closed_timestamp.target_duration = '10s'` in the system interface, this value will show up via `SHOW CLUSTER SETTING` in a virtual cluster SQL session. This changes the way that settings are picked up in virtual cluster, as follows: 1. if there is an override specifically for this tenant's ID (in `tenant_settings`), use that. 2. otherwise, if there is an override for the pseudo-ID 0 (in `tenant_settings` still, set via `ALTER TENANT ALL SET CLUSTER SETTING`), then use that. 3. **NEW** otherwise, if the class is TenantReadOnly and there is a custom value in `system.settings`, set via a regular `SET CLUSTER SETTING` in the system tenant, then use that. 4. otherwise, use the global default set via the setting's `Register()` call. ---- Prior to this patch, TenantReadOnly settings as observed from virtual clusters were defined as the following priority order: 1. if there is an override specifically for this tenant's ID (in `tenant_settings`), use that. 2. otherwise, if there is an override for the pseudo-ID 0 (in `tenant_settings` still, set via `ALTER TENANT ALL SET CLUSTER SETTING`), then use that. 3. otherwise, use the global default set via the setting's `Register()` call. Remarkably, this did not pick up any changes made via a plain `SET CLUSTER SETTING` statement via the system interface, which only modifies this setting's value in `system.settings` (thus not `tenant_settings`). This situation was problematic in two ways. To start, settings like `kv.closed_timestamp.target_duration` cannot be set solely in `system.tenant_settings`; they are also used in the storage layer and so must also be picked up from changes in `system.settings`. For these settings, it is common for operators to just issue the plain `SET CLUSTER SETTING` statement (to update `system.settings`) and simply forget to _also_ run `ALTER TENANT ALL SET CLUSTER SETTING`. This mistake is nearly unavoidable and would result in incoherent behavior, where the storage layer would use the customized value and virtual clusters would use the registered global default. The second problem is in mixed-version configurations, where the storage layer runs version N+1 and the SQL service runs version N of the executable. If the registered global default changes from version N to N+1, the SQL service would not properly pick up the new default defined in version N+1 of the storage layer. This patch fixes both problems as follows: - it integrates changes to TenantReadOnly settings observed in `system.settings`, to the watcher that tracks changes to `system.tenant_settings`. When a TenantReadOnly setting is present in the former but not the latter, a synthetic override is added. - it also initializes synthetic overrides for all the TenantReadOnly settings upon server initialization, from the registered global default, so that virtual cluster servers always pick up the storage layer's default as override. 111383: *: simplify tests r=yuzefovich a=knz All commits except the last are from #110758. Epic: CRDB-6671 Now that "tenant-ro" settings take their default from the system tenant's value, we do not need `ALTER TENANT ALL` for them any more. This patch simplifies test code accordingly. Rcommended by `@yuzefovich` in the review for #110758. 111440: cluster-ui: fix db page stories r=THardy98 a=THardy98 Epic: none This change fixes the stories for the database pages. Release note: None 111512: kv: correctly handle shared lock replays in KVNemesis r=nvanbenschoten a=arulajmani Previously, we'd return an AssertionFailed error if a SKIP LOCKED request discovered another request from its own transaction waiting in a lock's wait queue. In SQL's use of KV, this can only happen if the SKIP LOCKED request is being replayed -- so returning an error here is fine. However, this tripped KVNemesis up. This patch marks such errors, for the benefit of KVNemesis, and doesn't call them assertion failed errors. Fixes #111426 Fixes #111506 Fixes #111513 Release note: None Co-authored-by: Raphael 'kena' Poss <[email protected]> Co-authored-by: Thomas Hardy <[email protected]> Co-authored-by: Arul Ajmani <[email protected]>
Previous in sequence:
Needed for #110758
Epic: CRDB-6671
Prior to this patch, setting overrides in tests did not have their
value origin set properly. This patch fixes it.