*: insert/update or explain should not trigger table cache condition

[tiancaiamao]

What problem does this PR solve?

Close #29528.

Problem Summary:

A tiny fix after #29184

mysql> explain select * from t;
+-----------------------+---------+-----------+---------------+--------------------------------+
| id                    | estRows | task      | access object | operator info                  |
+-----------------------+---------+-----------+---------------+--------------------------------+
| TableReader_5         | 1.00    | root      |               | data:TableFullScan_4           |
| └─TableFullScan_4     | 1.00    | cop[tikv] | table:t       | keep order:false, stats:pseudo |
+-----------------------+---------+-----------+---------------+--------------------------------+
2 rows in set (0.00 sec)

mysql> explain select * from t;
+-------------------------+---------+-----------+---------------+--------------------------------+
| id                      | estRows | task      | access object | operator info                  |
+-------------------------+---------+-----------+---------------+--------------------------------+
| UnionScan_5             | 1.00    | root      |               |                                |
| └─TableReader_7         | 1.00    | root      |               | data:TableFullScan_6           |
|   └─TableFullScan_6     | 1.00    | cop[tikv] | table:t       | keep order:false, stats:pseudo |
+-------------------------+---------+-----------+---------------+--------------------------------+
3 rows in set (0.00 sec)

The explain query shouldn't trigger the cache table condition, because explain doesn't mean execute the query.

mysql> explain update t set c = c + 1 where id > 3;
+----------------------------+---------+-----------+---------------+------------------------------------------------+
| id                         | estRows | task      | access object | operator info                                  |
+----------------------------+---------+-----------+---------------+------------------------------------------------+
| Update_5                   | N/A     | root      |               | N/A                                            |
| └─UnionScan_7              | 1.00    | root      |               | gt(test.t.id, 3)                               |
|   └─TableReader_9          | 1.00    | root      |               | data:TableRangeScan_8                          |
|     └─TableRangeScan_8     | 1.00    | cop[tikv] | table:t       | range:(3,+inf], keep order:false, stats:pseudo |
+----------------------------+---------+-----------+---------------+------------------------------------------------+
4 rows in set (0.00 sec)

mysql> explain delete from t where id > 6;
+----------------------------+---------+-----------+---------------+------------------------------------------------+
| id                         | estRows | task      | access object | operator info                                  |
+----------------------------+---------+-----------+---------------+------------------------------------------------+
| Delete_5                   | N/A     | root      |               | N/A                                            |
| └─UnionScan_7              | 1.00    | root      |               | gt(test.t.id, 6)                               |
|   └─TableReader_9          | 1.00    | root      |               | data:TableRangeScan_8                          |
|     └─TableRangeScan_8     | 1.00    | cop[tikv] | table:t       | range:(6,+inf], keep order:false, stats:pseudo |
+----------------------------+---------+-----------+---------------+------------------------------------------------+
4 rows in set (0.00 sec)

Insert/Delete/Update should not trigger cache table condition too.
Because they are write operation, if UpdateLockForRead add the read lock, the write operation will wait for the lock to expire.

What is changed and how it works?

• if the operation is write, or explain, do not notify the table to update the read meta lock and load cache data
• defer panic to avoid the whole TiDB process exit
• make the test more stable

Check the UnionScan executor in the explain result is not a stable way to check whether the table cache is used by the query. Because the the notification is in another goroutine, when it runs is undetermined.

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

None

Not bug fix of released feature.

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• lcwangchao
• tangenta

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

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

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[lcwangchao]

Rest LGTM

[tiancaiamao]

Unstable test #28206

[2021-11-05T01:57:54.227Z] ----------------------------------------------------------------------
[2021-11-05T01:57:54.227Z] FAIL: db_partition_test.go:2956: testIntegrationSuite5.TestDropSchemaWithPartitionTable
[2021-11-05T01:57:54.227Z] 
[2021-11-05T01:57:54.227Z] db_partition_test.go:3006:
[2021-11-05T01:57:54.227Z]     c.Assert(recordsNum, Equals, 0)
[2021-11-05T01:57:54.227Z] ... obtained int = 4
[2021-11-05T01:57:54.227Z] ... expected int = 0
[2021-11-05T01:57:54.227Z] 

[tiancaiamao]

/run-check_dev_2

[AilinKid]

Unstable test #28206

[2021-11-05T01:57:54.227Z] ----------------------------------------------------------------------
[2021-11-05T01:57:54.227Z] FAIL: db_partition_test.go:2956: testIntegrationSuite5.TestDropSchemaWithPartitionTable
[2021-11-05T01:57:54.227Z] 
[2021-11-05T01:57:54.227Z] db_partition_test.go:3006:
[2021-11-05T01:57:54.227Z]     c.Assert(recordsNum, Equals, 0)
[2021-11-05T01:57:54.227Z] ... obtained int = 4
[2021-11-05T01:57:54.227Z] ... expected int = 0
[2021-11-05T01:57:54.227Z] 

your mention is in the wrong PR

[tiancaiamao]

Unstable test #28206

[2021-11-05T01:57:54.227Z] ----------------------------------------------------------------------
[2021-11-05T01:57:54.227Z] FAIL: db_partition_test.go:2956: testIntegrationSuite5.TestDropSchemaWithPartitionTable
[2021-11-05T01:57:54.227Z] 
[2021-11-05T01:57:54.227Z] db_partition_test.go:3006:
[2021-11-05T01:57:54.227Z]     c.Assert(recordsNum, Equals, 0)
[2021-11-05T01:57:54.227Z] ... obtained int = 4
[2021-11-05T01:57:54.227Z] ... expected int = 0
[2021-11-05T01:57:54.227Z] 

your mention is in the wrong PR

Nope, I mean check_dev_2 is unstable and cause this PR fail, so I re-run it. @AilinKid
And the failed case is already tracked in issue #28206... I fix that issue now that I come across it.

[tiancaiamao]

This PR fix a unstable case and the panic looks like that:

@AilinKid

[unconsolable]

Please add close issue #29528, thanks.

[tangenta]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 968293c

[ti-chi-bot]

@tiancaiamao: 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

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.