TiFlash accept lossless data type change for mydatetime(release-7.1)

[JaySon-Huang]

cherry-pick of #7815 with some adaption with release-7.1 branch

What problem does this PR solve?

Issue Number: close #7809

Problem Summary:

CREATE TABLE `t` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `create_time` datetime(0) DEFAULT CURRENT_TIMESTAMP(0),
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */
);
insert into t(id) values (10);
alter table t set tiflash replica 1;

set tidb_isolation_read_engines='tiflash';
select * from t;

alter table t modify column create_time datetime(3);
select * from t;
(1105, 'other error for mpp stream: From MPP<query:<query_ts:1689327674311914000, local_query_id:6, server_id:987888, start_ts:442847113852485633>,task_id:1>: Code: 49, e.displayText() = DB::Exception: Check schema[i].type->equals(*storage_schema[i].type) failed, schema[i].name = table_scan_1, schema[i].type->getName() = Nullable(MyDateTime(3)), storage_schema[i].name = create_time, storage_schema[i].type->getName() = Nullable(MyDateTime(0)), e.what() = DB::Exception,')

The root cause is that TiFlash does not detect the datatype change from mydatetime(0) to mydatetime(3) or timestamp(0) to timestamp(3) or time(0) to time(3).

tiflash/dbms/src/TiDB/Schema/SchemaBuilder.cpp

Lines 124 to 144 in 338634a

	bool typeDiffers(const TiDB::ColumnInfo & a, const TiDB::ColumnInfo & b)
	{
	if (a.tp != b.tp || a.hasNotNullFlag() != b.hasNotNullFlag() || a.hasUnsignedFlag() != b.hasUnsignedFlag())
	return true;
	if (a.tp == TypeEnum || a.tp == TypeSet)
	{
	if (a.elems.size() != b.elems.size())
	return true;
	for (size_t i = 0; i < a.elems.size(); i++)
	{
	if (a.elems[i].first != b.elems[i].first)
	return true;
	}
	return false;
	}
	else if (a.tp == TypeNewDecimal)
	{
	return a.flen != b.flen || a.decimal != b.decimal;
	}
	return false;
	}

Enlarging the fsp of mydatetime/timestamp/time is a lossless change, TiFlash should detect and change the data type in place. Narrowing down the fsp of mydatetime/timestamp/time is a lossy change, TiDB will add a temporary column and reorganize the column data as other lossy type change.

What is changed and how it works?

• Detect and accept the fsp enlarging of DATETIME/TIMESTAMP/TIME column type
  • Narrowing down in-place is not supported
• Cast the column type when reading the existing column data from disk to the new column type before returning to the compute layer

Check List

Tests

• Unit test
• Integration test
• 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 a bug that query fails after changing the `fsp` of `DATETIME`/`TIMESTAMP`/`TIME` column type

[JaySon-Huang]

/run-all-tests

[JaySon-Huang]

/run-all-tests

[JaySon-Huang]

/run-all-tests

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JinheLin, SeaRise

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 [JinheLin,SeaRise]

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:

• 2023-07-18 02:49:45.0561567 +0000 UTC m=+991476.826495411: ☑️ agreed by JinheLin.
• 2023-07-18 03:36:14.116581811 +0000 UTC m=+994265.886920522: ☑️ agreed by SeaRise.

[JaySon-Huang]

/run-all-tests