schema cache: record the ddl timestamp and associate schema cache with the timestamp for stale read

[hihihuhu]

What problem does this PR solve?

Issue Number: close #40740

Problem Summary:

What is changed and how it works?

when handle ddl, record the start ts of the transaction as the timestamp of the schema change. then when populate the schema cache, associate each schema version with a timestamp, and search the schema by timestamp for stale read.

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

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• tiancaiamao
• xhebox

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.

[ti-chi-bot]

Hi @hihihuhu. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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 kubernetes/test-infra repository.

[hihihuhu]

@xhebox could you help to take a look when you have a chance? thanks!

[xhebox]

Maybe we should rename loadschema(startTS uint64) to loadschema(timestamp uint64). This function will accept a timestamp that starts with the desired schema and schemadiff/metadata. It does not mean that startTS is the timestamp set by updateSchemaVersion.

[hihihuhu]

thanks! i updated to store startTs in schemadiff and use it as the timestamp of a schema version, i haven't tested it yet but want to get your opinion first to see if this is what you expect?

[hawkingrei]

/ok-to-test

[hawkingrei]

/test all

[hawkingrei]

/merge

[hawkingrei]

@hihihuhu Please fix it.

owner/manager_test.go:58:63: too many arguments in call to ic.Insert

	have (infoschema.InfoSchema, number, number)

	want (infoschema.InfoSchema, uint64)

owner/manager_test.go:118:63: too many arguments in call to ic.Insert

	have (infoschema.InfoSchema, number, number)

	want (infoschema.InfoSchema, uint64)

owner/manager_test.go:134:64: too many arguments in call to ic2.Insert

	have (infoschema.InfoSchema, number, number)

	want (infoschema.InfoSchema, uint64)

owner/manager_test.go:159:64: too many arguments in call to ic3.Insert

	have (infoschema.InfoSchema, number, number)

	want (infoschema.InfoSchema, uint64)

[hihihuhu]

/retest

[xhebox]

/merge

[ti-chi-bot]

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

Commit hash: dab3f0b

[hihihuhu]

@xhebox consider this is a fix of performance issue, is it possible to merge this into release-6.5? thanks!

[xhebox]

@xhebox consider this is a fix of performance issue, is it possible to merge this into release-6.5? thanks!

I think 'no'. We only pick fixes of bugs.