Fix SettingsConstraints erasing explicit settings before compatibility applies#97078
Merged
Fix SettingsConstraints erasing explicit settings before compatibility applies#97078
SettingsConstraints erasing explicit settings before compatibility applies#97078Conversation
Contributor
clickhouse-gh
bot
added
the
pr-bugfix
The previous commit removed the 'skip if unchanged' optimisation entirely, which broke readonly mode validation and settings change tracking. This fix takes a more targeted approach: only skip the optimisation when compatibility is present in the batch.
rienath
force-pushed
the
fix-settings
branch
from
c065293 to
320fc29
Compare
novikd
approved these changes
Feb 26, 2026
| # shellcheck source=../shell_config.sh | ||
| . "$CURDIR"/../shell_config.sh | ||
|
|
||
| QUERY_SKIP="SELECT value FROM system.settings WHERE name = 'use_skip_indexes_if_final'" |
Member
There was a problem hiding this comment.
The test can be done as a .sql file. It is a preferable option, because the fuzzer can use queries from .sql files, but not from bash scripts.
Member
Author
There was a problem hiding this comment.
We specifically want to test HTTP URL query parameters. I don't think it is possible to achieve through .sql
src/Access/SettingsConstraints.cpp
Outdated
Comment on lines
+220
to
+228
| bool has_compatibility = false; | ||
| for (const auto & change : changes) | ||
| { | ||
| if (change.name == "compatibility") | ||
| { | ||
| return !checkImpl(current_settings, change, THROW_ON_VIOLATION, source); | ||
| }); | ||
| has_compatibility = true; | ||
| break; | ||
| } | ||
| } |
Member
There was a problem hiding this comment.
Suggested change
| bool has_compatibility = false; | |
| for (const auto & change : changes) | |
| { | |
| if (change.name == "compatibility") | |
| { | |
| return !checkImpl(current_settings, change, THROW_ON_VIOLATION, source); | |
| }); | |
| has_compatibility = true; | |
| break; | |
| } | |
| } | |
| bool has_compatibility = changes.tryGet("compatibility") != nullptr; |
Member
Author
There was a problem hiding this comment.
Thanks! This is much more elegant
Member
|
It broke the CI, reverting here: #98515 |
Member
Author
Member
|
On one side, yes, but anything that breaks our CI is not right. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We erased settings from the changes vector when their value matches the current server value (as an optimization to skip constraint checks for unchanged values). This is wrong when the same batch contains a compatibility setting. The compatibility mechanism resets settings to historical defaults, which can change the baseline after the constraints check. Any erased setting is then lost and never re-applied.
Example: server has
use_skip_indexes_if_final=1(default since 25.6). Client sendscompatibility=24.12&use_skip_indexes_if_final=1. The constraints check sees1==1, erases it. Thencompatibility=24.12reverts the setting to 0. The explicit=1is gone.Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Fix a bug where explicit settings sent alongside
compatibilityin the same request could be silently ignored when their value matched the server default.