fix: preserve clone auto-increment continuation - #27154
Open
gouhongshen wants to merge 4 commits into
Open
Conversation
gouhongshen
force-pushed
the
agent/issue-27092-853b7421
branch
from
August 14, 2026 07:53
4a1a0e6 to
34cfec2
Compare
1 task
Contributor
Author
|
One unrelated CI blocker remains on exact head
Normal Ubuntu UT, SCA, Coverage UT, shared build, and PESSIMISTIC BVT passed. All changed clone cases passed inside attempt-2 PROXY BVT: The single permitted failed-job rerun is exhausted. Attempt 2 is terminal and will not be rerun again. |
1 task
XuPeng-SH
approved these changes
Aug 17, 2026
XuPeng-SH
left a comment
XuPeng-SH
left a comment
Contributor
There was a problem hiding this comment.
Deep review completed on exact head 9cf7087.
The fresh-clone versus ALTER-copy allocator ownership split is consistent: visible columns on a new table are rebuilt from the transaction-consistent copied-row maximum plus schema/session floors, while retained-ID ALTER paths and hidden internal allocators preserve their fenced state. I also verified the issue reproduction against a locally built exact-head server (source next 4, clone insert 4, clone next 5), explicit AUTO_INCREMENT=100, and the clone-of-clone empty-source counterexample. Focused checked-allocator tests, the full table_clone package, and focused race tests passed. No blocking code issue found.
gouhongshen
force-pushed
the
agent/issue-27092-853b7421
branch
from
August 25, 2026 18:41
9cf7087 to
6ad3ad6
Compare
This was referenced Aug 28, 2026
Contributor
Author
|
@Mergifyio queue |
Contributor
Merge Queue Status
Waiting for any of
All conditions
|
1 task
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
3 participants
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.
What type of PR is this?
Which issue(s) this PR fixes:
Fixes #27092
What this PR does / why we need it:
Root cause
Fresh table clones copied the source row from
mo_catalog.mo_increment_columnsinto the destination allocator. That row offset is the upper bound of a reserved allocation batch (10,000 in the reproducer), not the next source-session value (4). Because a fresh clone has a new table ID and an independent allocator, transferring that reservation made its first generated ID 10,001.The persisted table definition separately carries explicit schema lower bounds such as
ALTER TABLE ... AUTO_INCREMENT = 100. Those are user-visible state and must still be preserved.Changes
AUTO_INCREMENT, explicit transactions, and historical snapshots.Issue-to-test proof
4, clone next5, and first cloned-table insert4for table, database, and both Data Branch clone forms.1; a source whose largest row was deleted seeds the independent clone from the copied maximum; explicitAUTO_INCREMENT = 100inserts100; snapshot clone asserts snapshot-visible rows plus exact4 / 5inserted/next values.10and11, then assigns12to the first destination insert.40001through40006, without introducing a new 10,000-value gap at each clone.Verification
Latest semantic rebase: base
fcc8ff3b030fd38c8ddc6e791858fc89dfa22b63/ clone head029164150af0edb6f09321299788dc6daa0f0560was rebased conflict-free ontomainatfb56746be170fa7e51191853f9e9f5a518ef69e0, producing exact head6700b5235dbc1421fbea1ff5558a3ebb582d6684.git range-diff fcc8ff3b03..029164150a origin/main..HEAD: all four clone patches are equivalent.ff530dfc6cb58fd343bc0663b95c917a95aa40fc.029164150a;git diff --check origin/main...HEADpassed and the final diff remains exactly the intended six clone files.6700b5235d.TestIssue277xxDDLConsistencypassed all five public DDL subtests in 61.7s, including ALTER COPY foreign-key preservation and concurrent stale-index retry.f2d9c702a2passed the eight clone tests with 20 feature-quota/barrier/authentication tests, the concurrent Data Branch and snapshot quota two-CN tests, and the catalog-probe error test. The final incoming commit changes only compile/plan DDL paths and does not invalidate those frontend quota contracts.33251676650attempts 1 and 2 on superseded patch-equivalent head896756fac4passed shared build, normal Ubuntu UT, SCA, Coverage UT on attempt 2, and PROXY BVT. Attempt 2 reproduced only unrelated [Bug]: mo-tester sorts rows by ignored columns, causing false BVT failures #27164 in PESSIMISTIC BVT; aggregate Coverage was derivative. The single failed-job rerun is exhausted.6700b5235d.CI investigation
33251676650attempts 1 and 2 reproduced the same mo-tester false negative on exact then-current head896756fac4.snapshot/sys_restore_system_table_to_sys_account.sqlcompleted 313 statements with 311 successful. At SQL rows 167 and 183, expected ignoredproc_idvalues were1920000/1920001, actual ignored values were9/10, and mo-tester cross-pairedtest_if_hit_second_elseifwithtest_if_hit_elseatrow:0,column:1. The error list contains no other SQL.clone_auto_increment_state.sql65/65,table_clone.sql74/74, andtemporary_table_clone.sql163/163. The six-file clone-only diff changes neither the failing snapshot case nor mo-tester. No in-scope PR code change is warranted; repeated exact-head evidence is recorded on [Bug]: mo-tester sorts rows by ignored columns, causing false BVT failures #27164.prerequisites_ready: falsefor generation33251676650-1and exits before coverage processing.33251676650was rerun for failed jobs exactly once. Attempt 2 is terminal and will not be rerun again.pr-size-labelTLS failure occurred before PR files were read, and the same-head rerun passed.5a8588b07echanged the unrelated snapshot case to order stored-procedure rows. It was excluded during scope-only rebases because fix: preserve clone auto-increment continuation #27154 is the clone auto-increment fix. [Bug]: mo-tester sorts rows by ignored columns, causing false BVT failures #27164 remains open/deferred, and no standalone PR for that commit was found.Residual risks
A fresh clone intentionally owns an independent allocator. If the highest generated source rows were deleted, the clone starts after the highest row it actually copied rather than inheriting an unused cached range from the source CN. Explicit schema lower bounds remain preserved. There are no catalog, wire-format, or API changes in this PR, and the fix does not read or mutate source CN allocator caches.