*: fix the origin_default_value issue in disaggregated mode

[zimulala]

What problem does this PR solve?

Issue Number: close #9665

Problem Summary:

What is changed and how it works?

Since the TiDB add new column operation does not actually write the new column data, it simply logs it to `origin_default_value`.
In disaggregated mode, the default value may be read using tipb passing the default value. The original logic is to pass the default value of tipb to the default value of ColumnInfo (calling defaultValueToField).

After obtaining the default value of tipb, decode it, and then use the defaultValueToField value for processing.

Check List

Tests

• Unit test
• Integration test

tidb> set session tidb_isolation_read_engines='tiflash';
tidb> select col1, col2, col3, col4, col5, col6, col7, col8, col9, col10, col11, col12, col13, col14, hex(col15) from test.t;

Before this PR:

+------+------+------+------+------+-------+------+------+------+-------+-------+-------+----------+----------+-------+
| col1 | col2 | col3 | col4 | col5 | col6  | col7 | col8 | col9 | col10 | col11 | col12 | col13    | col14    |col15 |
+------+------+------+------+------+-------+------+------+------+-------+-------+-------+----------+----------+-------+
|    0 | 0000 | 0.00 | 0.00 |    0 | sss | NULL | NULL | 0000 |       |       | NULL  | 00:00:00 | 00:00:00 | NULL  |
|    0 | 0000 | 0.00 | 0.00 |    0 | sss | NULL | NULL | 0000 |       |       | NULL  | 00:00:00 | 00:00:00 | NULL  |
|    0 | 0000 | 0.00 | 0.00 |    0 | sss | NULL | NULL | 0000 |       |       | NULL  | 00:00:00 | 00:00:00 | NULL  |
+------+------+------+------+------+-------+------+------+------+-------+-------+-------+----------+----------+-------+

After this PR:

+------+------+------+------+------+------+---------------------+---------------------+------+--------+--------+---------------------+----------+-------+------------+
| col1 | col2 | col3 | col4 | col5 | col6 | col7                | col8                | col9 | col10  | col11  | col12               | col13    | col14 | hex(col15) |
+------+------+------+------+------+------+---------------------+---------------------+------+--------+--------+---------------------+----------+-------+------------+
|   30 | 0000 | 0.00 | 1.23 |  123 | sss  | 2017-02-11 00:00:00 | 2018-11-04 23:12:03 | 2012 | value3 | value1 | 2018-11-04 23:12:03 | 12:18:30 | NULL  | 10203      |
|   30 | 0000 | 0.00 | 1.23 |  123 | sss  | 2017-02-11 00:00:00 | 2018-11-04 23:12:03 | 2012 | value3 | value1 | 2018-11-04 23:12:03 | 12:18:30 | NULL  | 10203      |
|   30 | 0000 | 0.00 | 1.23 |  123 | sss  | 2017-02-11 00:00:00 | 2018-11-04 23:12:03 | 2012 | value3 | value1 | 2018-11-04 23:12:03 | 12:18:30 | NULL  | 10203      |
+------+------+------+------+------+------+---------------------+---------------------+------+--------+--------+---------------------+----------+-------+------------+

• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Fix the bug that in the disaggregated storage and compute architecture, the query result of added column is not correct

[sre-bot]

All committers have signed the CLA.

[zimulala]

PTAL @Lloyd-Pottiger

[Lloyd-Pottiger]

set tidb_column_info.origin_default_value = tipb_column_info.default_val(); if val.get<Int64>() != 0 ?

[zimulala]

Yes. If we don't do this, after alter table t add column col2 year not null;, we get this data is 2000 not 0000.

[zimulala]

PTAL @Lloyd-Pottiger

[Lloyd-Pottiger]

LGTM

[JaySon-Huang]

LGTM

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JaySon-Huang, Lloyd-Pottiger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JaySon-Huang,Lloyd-Pottiger]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-11-22 08:10:21.654749461 +0000 UTC m=+192009.274403977: ☑️ agreed by Lloyd-Pottiger.
• 2024-11-25 09:36:34.430402402 +0000 UTC m=+456382.050056918: ☑️ agreed by JaySon-Huang.

[ti-chi-bot]

@zimulala: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

trigger some heavy tests which will not run always when PR updated.

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

Instructions 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 ti-community-infra/tichi repository.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.5: #9683.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-8.1: #9719.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-8.5: #9729.