Skip to content

[fix](fe) Avoid reusing dropped column unique ids - #67239

Draft
Yukang-Lian wants to merge 1 commit into
apache:masterfrom
Yukang-Lian:codex/fix-dropped-column-unique-id
Draft

[fix](fe) Avoid reusing dropped column unique ids#67239
Yukang-Lian wants to merge 1 commit into
apache:masterfrom
Yukang-Lian:codex/fix-dropped-column-unique-id

Conversation

@Yukang-Lian

Copy link
Copy Markdown
Collaborator

What problem does this PR solve?

Issue Number: None

Related PR: #63173

Problem Summary:

Light schema change uses column unique IDs to match FE slots with columns stored
in existing segments. Some supported legacy metadata can contain a
maxColUniqueId lower than an ID that is still present in the current schema.

The DROP COLUMN path replaced the index schema before preserving its unique-ID
high-water mark. Dropping the highest-ID column could therefore lose that
historical ID, and a later ADD COLUMN could assign it again. Existing segments
could then be interpreted as containing values for the new column.

This change normalizes maxColUniqueId when metadata is deserialized and
preserves the maximum from both the old and new schemas during light schema
changes. It prevents future drops from losing a high-water mark that is still
available in current metadata.

This is a preventive fix for metadata whose high-water mark is still inferable.
It cannot reconstruct an ID that was already absent from both the schema and
maxColUniqueId before upgrade.

Release note

Prevent future light schema changes from reusing dropped column unique IDs when
a legacy high-water mark is stale. Metadata that had already lost its historical
high-water mark before upgrade is not repaired by this change.

Check List (For Author)

  • Test

    • Regression test
      • Added a Docker fault-injection test that writes an old segment, drops
        and re-adds a column, verifies the old row returns NULL, and verifies
        a new row returns the newly written value.
      • Ran LOCAL_DORIS_PATH=$PWD/.doris-compose ./run-regression-test.sh --run -d fault_injection_p0 -s test_readd_dropped_column_unique_id -image doris-pr63173-test:latest -runMode not_cloud.
    • Unit Test
      • Added DDL coverage for non-reused IDs and metadata deserialization
        coverage for repairing a stale maximum while preserving a higher one.
      • Ran ./run-fe-ut.sh --run 'org.apache.doris.alter.SchemaChangeHandlerTest#testReaddDroppedValueColumnUsesNewUniqueId,org.apache.doris.catalog.MaterializedIndexMetaTest'.
      • Ran NODE_OPTIONS=--openssl-legacy-provider ./build.sh --fe.
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes. Light schema changes preserve the column unique-ID high-water
      mark so newly added columns do not reuse IDs still known to the metadata.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

### What problem does this PR solve?

Issue Number: None

Related PR: apache#63173

Problem Summary: Light schema change uses column unique IDs to match FE slots
with columns stored in existing segments. Some supported legacy metadata can
contain a maxColUniqueId lower than an ID that is still present in the current
schema.

The DROP COLUMN path replaced the index schema before preserving its unique-ID
high-water mark. Dropping the highest-ID column could therefore lose that
historical ID, and a later ADD COLUMN could assign it again. Existing segments
could then be interpreted as containing values for the new column.

This change normalizes maxColUniqueId when metadata is deserialized and
preserves the maximum from both the old and new schemas during light schema
changes. It prevents future drops from losing a high-water mark that is still
available in current metadata. It cannot reconstruct an ID that was already
absent from both the schema and maxColUniqueId before upgrade.

### Release note

Prevent future light schema changes from reusing dropped column unique IDs when
a legacy high-water mark is stale. Metadata that had already lost its historical
high-water mark before upgrade is not repaired by this change.

### Check List (For Author)

- Test: Regression test / Unit Test
    - `./run-fe-ut.sh --run 'org.apache.doris.alter.SchemaChangeHandlerTest#testReaddDroppedValueColumnUsesNewUniqueId,org.apache.doris.catalog.MaterializedIndexMetaTest'`
    - `LOCAL_DORIS_PATH=$PWD/.doris-compose ./run-regression-test.sh --run -d fault_injection_p0 -s test_readd_dropped_column_unique_id -image doris-pr63173-test:latest -runMode not_cloud`
    - `NODE_OPTIONS=--openssl-legacy-provider ./build.sh --fe`
- Behavior changed: Yes. Light schema changes preserve the column unique-ID
  high-water mark so newly added columns do not reuse IDs still known to the
  metadata.
- Does this need documentation: No

Co-authored-by: Siyang Tang <tangsiyang@selectdb.com>
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@Yukang-Lian

Copy link
Copy Markdown
Collaborator Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor
TPC-H: Total hot run time: 16610 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit d4562f167565c6cc90a46276ccb7343579787a96, data reload: false

------ Round 1 ----------------------------------
============================================
q1	17583	2998	2984	2984
q2	2105	253	221	221
q3	10220	900	499	499
q4	4665	253	202	202
q5	7676	563	376	376
q6	134	118	94	94
q7	529	510	385	385
q8	9236	902	944	902
q9	3441	2408	2406	2406
q10	6504	872	706	706
q11	390	195	177	177
q12	604	264	195	195
q13	18134	1507	1162	1162
q14	158	148	138	138
q15	q16	428	394	370	370
q17	1308	878	817	817
q18	3130	2240	2207	2207
q19	1122	928	703	703
q20	366	287	196	196
q21	4829	1637	1833	1637
q22	317	269	233	233
Total cold run time: 92879 ms
Total hot run time: 16610 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	3330	3300	3264	3264
q2	514	386	366	366
q3	2207	2335	2243	2243
q4	1181	1157	889	889
q5	2174	2141	2097	2097
q6	166	117	87	87
q7	1019	936	861	861
q8	1588	1388	1383	1383
q9	3110	3061	3059	3059
q10	1831	1792	1630	1630
q11	348	267	249	249
q12	445	429	336	336
q13	1476	1509	1151	1151
q14	165	178	156	156
q15	q16	386	391	354	354
q17	3674	3298	3183	3183
q18	4821	4408	4668	4408
q19	865	817	800	800
q20	1097	999	834	834
q21	3817	3125	3372	3125
q22	405	346	330	330
Total cold run time: 34619 ms
Total hot run time: 30805 ms

@hello-stephen

Copy link
Copy Markdown
Contributor
TPC-DS: Total hot run time: 81548 ms
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit d4562f167565c6cc90a46276ccb7343579787a96, data reload: false

query5	4303	427	329	329
query6	372	131	124	124
query7	4957	419	230	230
query8	290	122	113	113
query9	8684	2874	2848	2848
query10	404	208	179	179
query11	5377	1031	919	919
query12	115	68	68	68
query13	1194	447	324	324
query14	6131	2184	2100	2100
query14_1	1950	1943	1918	1918
query15	178	124	112	112
query16	938	387	355	355
query17	804	450	362	362
query18	2338	353	236	236
query19	168	130	105	105
query20	70	67	68	67
query21	197	99	85	85
query22	5463	5371	5232	5232
query23	6680	6111	6125	6111
query23_1	6082	6033	5967	5967
query24	7281	1074	746	746
query24_1	759	794	772	772
query25	419	268	242	242
query26	1217	230	117	117
query27	2810	428	253	253
query28	4705	1513	1491	1491
query29	914	415	331	331
query30	248	155	127	127
query31	813	387	325	325
query32	131	74	71	71
query33	447	204	167	167
query34	989	806	475	475
query35	398	402	327	327
query36	565	546	541	541
query37	115	78	67	67
query38	990	828	825	825
query39	484	462	470	462
query39_1	450	448	460	448
query40	198	86	75	75
query41	52	52	51	51
query42	72	66	73	66
query43	237	236	203	203
query44	1006	543	553	543
query45	108	104	101	101
query46	781	838	523	523
query47	756	776	714	714
query48	315	306	223	223
query49	536	250	193	193
query50	747	259	191	191
query51	8040	7873	7949	7873
query52	66	65	58	58
query53	190	198	145	145
query54	216	169	174	169
query55	68	58	54	54
query56	179	191	172	172
query57	684	670	627	627
query58	176	147	169	147
query59	1287	1220	1102	1102
query60	248	193	170	170
query61	116	112	112	112
query62	360	195	184	184
query63	169	134	141	134
query64	2723	683	595	595
query65	1570	1582	1562	1562
query66	1819	284	222	222
query67	9838	9587	9753	9587
query68	2960	1229	771	771
query69	333	219	188	188
query70	647	633	626	626
query71	248	168	167	167
query72	2304	1677	1534	1534
query73	634	569	326	326
query74	1972	1229	1145	1145
query75	1185	1089	957	957
query76	2298	724	561	561
query77	251	265	205	205
query78	3905	3686	3192	3192
query79	2388	830	591	591
query80	1602	305	276	276
query81	491	153	129	129
query82	624	120	99	99
query83	298	208	186	186
query84	297	113	87	87
query85	789	359	357	357
query86	395	177	179	177
query87	998	971	904	904
query88	2809	2121	2097	2097
query89	281	197	176	176
query90	1941	129	127	127
query91	130	116	98	98
query92	79	68	69	68
query93	1526	1024	676	676
query94	637	239	235	235
query95	505	328	227	227
query96	832	585	268	268
query97	1057	1046	1028	1028
query98	144	138	133	133
query99	417	351	314	314
Total cold run time: 177430 ms
Total hot run time: 81548 ms

@hello-stephen

Copy link
Copy Markdown
Contributor
ClickBench: Total hot run time: 14.63 s
machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit d4562f167565c6cc90a46276ccb7343579787a96, data reload: false

query1	0.01	0.01	0.00
query2	0.08	0.04	0.04
query3	0.24	0.10	0.10
query4	1.60	0.09	0.08
query5	0.16	0.16	0.16
query6	1.27	0.66	0.68
query7	0.03	0.01	0.00
query8	0.04	0.02	0.02
query9	0.29	0.20	0.22
query10	0.36	0.36	0.33
query11	0.17	0.12	0.11
query12	0.15	0.12	0.12
query13	0.29	0.30	0.30
query14	0.46	0.46	0.45
query15	0.35	0.35	0.34
query16	0.22	0.22	0.22
query17	0.73	0.69	0.70
query18	0.17	0.16	0.15
query19	1.10	1.20	1.19
query20	0.02	0.00	0.00
query21	15.45	0.17	0.12
query22	5.08	0.05	0.05
query23	16.16	0.24	0.10
query24	3.12	0.32	0.27
query25	0.10	0.05	0.04
query26	0.73	0.16	0.11
query27	0.04	0.04	0.03
query28	3.66	0.54	0.26
query29	12.50	3.16	2.56
query30	0.25	0.13	0.12
query31	2.76	0.39	0.18
query32	3.50	0.31	0.24
query33	1.36	1.51	1.40
query34	15.37	2.17	1.76
query35	1.76	1.76	1.71
query36	0.45	0.31	0.28
query37	0.06	0.04	0.04
query38	0.05	0.04	0.03
query39	0.03	0.02	0.02
query40	0.11	0.08	0.08
query41	0.07	0.02	0.03
query42	0.03	0.02	0.02
query43	0.03	0.03	0.03
Total cold run time: 90.41 s
Total hot run time: 14.63 s

@Yukang-Lian
Yukang-Lian marked this pull request as draft September 10, 2026 03:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants