-
Notifications
You must be signed in to change notification settings - Fork 6.1k
table: Non-clustered table non-unique global index needs partid in key, v1 #65380
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
base: master
Are you sure you want to change the base?
table: Non-clustered table non-unique global index needs partid in key, v1 #65380
Conversation
…s compatibility Add GlobalIndexVersion field to IndexInfo to enable backwards compatible evolution of global index key formats. Only non-clustered tables with non-unique global indexes use version 2, which encodes partition ID in the key using PartitionIDFlag to prevent duplicate handle collisions after EXCHANGE PARTITION. Clustered tables and unique indexes are not affected by the duplicate handle issue and continue using version 0 (legacy format). Clustered tables have unique primary keys that include the partitioning column, so no collisions are possible. Version validation ensures unsupported future versions are rejected with clear error messages. This approach allows gradual migration while prioritizing correctness for affected index types. Related to pingcap#65289. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @mjonss. Thanks for your PR. PRs from untrusted users cannot be marked as trusted with I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #65380 +/- ##
================================================
+ Coverage 77.7820% 79.4342% +1.6521%
================================================
Files 2001 1949 -52
Lines 545618 536275 -9343
================================================
+ Hits 424393 425986 +1593
+ Misses 119563 108825 -10738
+ Partials 1662 1464 -198
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
/ok-to-test |
|
/test all |
…MARY KEY Problem: When creating a partitioned table with an inline PRIMARY KEY (e.g., `a INT PRIMARY KEY`) followed by global indexes in the same CREATE TABLE statement, the global index was incorrectly assigned GlobalIndexVersion V1 even when the table was clustered. This happened because inline PRIMARY KEY definitions are converted to constraints and appended to the end of the constraints list (after table- level constraints). When BuildTableInfo processes constraints in order, global indexes are built before the PRIMARY KEY constraint is processed, so HasClusteredIndex() returns false, causing incorrect version assignment. Root Cause: In buildColumnsAndConstraints (create_table.go:1063), inline PRIMARY KEY constraints from column definitions are appended after table constraints: constraints = append(constraints, cts...) So for `CREATE TABLE t (a INT PRIMARY KEY, key idx(b) global)`, constraints are processed as: 1. key idx(b) global <- built first, sees HasClusteredIndex()=false 2. primary key(a) <- processed last, sets PKIsHandle=true Solution: Added a pre-scan loop before constraint processing in BuildTableInfo that: 1. Scans all constraints to find PRIMARY KEY 2. Determines if table will be clustered (PKIsHandle/IsCommonHandle) 3. Sets clustering flags before any indexes are built This ensures HasClusteredIndex() returns correct value when building global indexes, so: - Clustered tables get GlobalIndexVersion = 0 (correct) - Non-clustered tables with non-unique global indexes get V1 (correct) The pre-scan handles expression-based PKs correctly without building hidden columns (expression PKs can't be PKIsHandle, so they become IsCommonHandle). Impact: - Preserves constraint ordering (no SHOW CREATE TABLE changes) - Fixes TestGlobalIndexVersion1 which was failing - No performance impact (lightweight pre-scan) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
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.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.
…lustered-non-unique-add-partid-to-key-65289
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.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (1)
pkg/ddl/create_table.go:1409
- The clustering index information (PKIsHandle, IsCommonHandle, CommonHandleVersion) is being set twice - once in the pre-scan (lines 1332-1348) and again in the main loop (lines 1403-1409). This duplication could lead to maintenance issues. While this appears intentional to ensure the information is available early for BuildIndexInfo calls, the duplicate logic increases the risk of inconsistencies if one location is updated without the other. Consider adding a comment in the main loop referencing the pre-scan or refactoring to eliminate the duplication by extracting the logic into a shared function.
if ShouldBuildClusteredIndex(ctx.GetClusteredIndexDefMode(), constr.Option, isSingleIntPK) {
if isSingleIntPK {
tbInfo.PKIsHandle = true
} else {
tbInfo.IsCommonHandle = true
tbInfo.CommonHandleVersion = 1
}
|
/retest |
1 similar comment
|
/retest |
Co-authored-by: Copilot <[email protected]>
…lustered-non-unique-add-partid-to-key-65289
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.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
|
/retest |
…lustered-non-unique-add-partid-to-key-65289
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.
Pull request overview
Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.
…lustered-non-unique-add-partid-to-key-65289
|
/retest |
What problem does this PR solve?
Issue Number: close #65289
Problem Summary:
Non-clustered partitioned table's non-unique Global Index key format is not unique per index entry if _tidb_rowid is not unique across all partitons, which they may not be after EXCHANGE PARTITION.
What changed and how does it work?
Create a new version of Global Index, which also includes the partition id in the key, while still keeping the partition id in the value part of the index entry, to not extend the scope to also affect the reading part of the index (to be followed by another PR which adds yet another global index version, that only has the partition id in the key, and not in the value).
The implementation consists of two different changes:
BuildIndexInfowe need to know iftblInfo.HasClusteredIndex(), and that might not be set correctly yet, if the primary key was not handled yet inBuildTableInfo, so we needed to do a pre-scan of the constraints to set it properly first, before actually handling all indexesfetchRowColVals()to properly set the handle as a PartitionHandle.Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.