Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
planner: fix update panic when update in prepare and execute #26759
planner: fix update panic when update in prepare and execute #26759
Changes from 3 commits
ccf66fd
e66e134
0b94fdc
47b7c9a
843fabe
0644de4
9ba22b5
91127a1
39bdf6f
7f75aac
d04b0dd
dbe84bf
525a740
b358909
f5d7f0a
1d5e335
13e0a6f
d6ec84b
4548083
44146c4
3be9a6f
3f0de0e
e9227ed
2959ab5
48b66e4
4dd7843
8086a16
42b381b
d41aa35
5a20e18
2e1d6da
52f774d
963f737
ac14ea0
da070d7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if executing normal statements without prepare-execute model? It affects those statements now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's ok, it's is a normal limitation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GetInfoSchema()
is not equavalent tosctx.GetSessionVars().TxnCtx.InfoSchema
, e.g. snapshot and stale infoschema. And it is intended that the schema of session is not always the global latest, it should be session-latest except some special cases likeforUpdate
. In fact, I found 2pc relied on this behavior.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found 2pc relied on this behavior.
I don't find this? where is it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only find it works on the
resolveAccessPaths
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right. these two information can be different! may be for this sort of
forUpdateRead
case, they should be the same.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2pc relied on schema checker and amender. Changing infoschema between
optimize
andexecute
may bypass the checker and fail the correctness of amender(for most cases? I don't know whyforUpdateRead
will ask for the latest exactly, seems it will cause inconsistency frequently if it is not the latest in some parallel cases)You reminds me that I've suggested to remove these lines, because I have moved the logic of choosing correct infoschema to the outside https://github.com/pingcap/tidb/pull/26759/files#r679868151: these lines should be stub, the correct infoschema has been chosen. But got refused for risks, because the transaction reviewer seems can not track the whole execution path, too.
I've looked more closely,
server/conn
will dispatchprepare
andexecute
into the one in session, so yes, the correct infoschema will be passed down from session down to here. And chasing a even newer infoschema between two closely coupledoptimize
andexecute
is non-sense for me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a whole new proposal to define the behavior of concurrent DDL, because sync the latest = use the global latest. So all sessions will share the same infoschema as long as possible. It is been a gray area for a long time. I believe a talk to the transaction and runtime team is must.