executor: fix a panic when batch point get is used for partition table (#23652)

[ti-srebot]

cherry-pick #23652 to release-4.0
You can switch your code base to this Pull Request by using git-extras:

# In tidb repo:
git pr https://github.com/pingcap/tidb/pull/23682

After apply modifications, you can push your change to this PR via:

git push git@github.com:ti-srebot/tidb.git pr/23682:release-4.0-67874c579a3c

---

What problem does this PR solve?

5.0.0-rc panic stack:

{"level":"INFO","time":"2021/03/25 10:54:26.757 +08:00","caller":"conn.go:809","message":"command dispatched failed","conn":49,"connInfo":"id:49, addr:11.186.250.167:57210 status:10, collation:utf8mb4_general_ci, user:media_inter_r","command":"Execute","status":"inTxn:0, autocommit:1","sql":"SELECT `imp_date`, `media_id`, `app`, `article_likepv`, `article_collectpv`, `article_relaypv`, `article_commentpv`, `video_likevv`, `video_collectvv`, `video_relayvv`, `video_commentvv` FROM `media_interact_daily_6`.`t_media_interact_daily_4` WHERE (media_id=? AND app=? AND ((imp_date>=? AND imp_date<=?) OR (imp_date>=? AND imp_date<=?) OR (imp_date>=? AND imp_date<=?) OR (imp_date>=? AND imp_date<=?))) [arguments: (19790046, all, 2021-03-24, 2021-03-24, 2021-03-23, 2021-03-23, 2021-03-17, 2021-03-17, 2021-02-22, 2021-02-22)]","txn_mode":"OPTIMISTIC","err":"runtime error: integer divide by zero
github.com/pingcap/tidb/executor.(*recordSet).Next.func1
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/adapter.go:125
runtime.gopanic
	/usr/local/go/src/runtime/panic.go:679
runtime.panicdivide
	/usr/local/go/src/runtime/panic.go:178
github.com/pingcap/tidb/executor.getPhysID
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/batch_point_get.go:427
github.com/pingcap/tidb/executor.(*BatchPointGetExec).initialize
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/batch_point_get.go:195
github.com/pingcap/tidb/executor.(*BatchPointGetExec).Next
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/batch_point_get.go:143
github.com/pingcap/tidb/executor.Next
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/executor.go:278
github.com/pingcap/tidb/executor.(*recordSet).Next
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/executor/adapter.go:129
github.com/pingcap/tidb/server.(*tidbResultSet).Next
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/driver_tidb.go:298
github.com/pingcap/tidb/server.(*clientConn).writeChunks
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/conn.go:1732
github.com/pingcap/tidb/server.(*clientConn).writeResultset
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/conn.go:1692
github.com/pingcap/tidb/server.(*clientConn).handleStmtExecute
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/conn_stmt.go:213
github.com/pingcap/tidb/server.(*clientConn).dispatch
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/conn.go:1050
github.com/pingcap/tidb/server.(*clientConn).Run
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/conn.go:792
github.com/pingcap/tidb/server.(*Server).onConn
	/home/jenkins/agent/workspace/build-linux-amd64-enterprise/go/src/github.com/pingcap/tidb/server/server.go:461
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1357

Problem Summary:

The 'divide by zero' error should not happen, and in fact, partition table should not use BatchPointGet executor in the physical plan phase.

The root cause should be our improper handle of the partition meta info.
For historical reason, the meta information of a partition table maybe not nil, but its Enable field is false.
That means it's not really a partition table.
We should use GetPartitionInfo() check is a table a real partition table or not.

What is changed and how it works?

What's Changed:

Change direct access of struct field tableInfo.Partition to tableInfo.GetPartition()

How it Works:

GetPartitionInfo() will check the Enable field, we should always use it instead of using tableInfo.Partition .

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• Unit test

Release note

• Fix a panic on batch point get for non-partitioned table with partition meta information. When a cluster is upgrade from a old version, its partition meta information maybe not null, but the Enable field is false, it should be treat as a non-partitioned table.

[ti-srebot]

/run-all-tests

[ti-srebot]

@tiancaiamao you're already a collaborator in bot's repo.

[tiancaiamao]

I find 4.0 is not really using batch point get for the case, so the panic will not be triggered.
Anyway, it's still better to cherry-pick this PR, in case that getPhysID() is called somewhere else and panic.

[djshow832]

/lgtm

[ti-chi-bot]

@djshow832: /lgtm is only allowed for the reviewers in list.

In response to this:

/lgtm

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.

[djshow832]

/lgtm

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• djshow832
• qw4990

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 writing /lgtm in a comment.
Reviewer can cancel approval by writing /lgtm cancel in a comment.

[qw4990]

/merge

[ti-chi-bot]

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

Commit hash: 85f917d

[ti-chi-bot]

@ti-srebot: 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.