Why is the error code from the official documentation different from the actual error code for the same error, or am I looking in the wrong place?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 为啥同一个错误,官方的错误码和实际报错的错误码不相同,还是说我没有找对?

| username: TiDBer_ySLWWMGO

【TiDB Usage Environment】Production Environment
【TiDB Version】v7.0.0
【Reproduction Path】Large statement execution
【Encountered Issue: Memory Overflow】
【Resource Configuration】Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
【Attachments: Screenshots/Logs/Monitoring】

Official


Actual Execution

| username: Running | Original post link

Perhaps the operation tool has been redefined, as long as the problem is solved.

| username: TiDBer_ySLWWMGO | Original post link

Really? I’m just worried that this might be the reason, and it will lead to inaccurate problem localization in the future.

| username: TiDBer_ySLWWMGO | Original post link

After all, there are still a lot of error codes.

| username: tidb菜鸟一只 | Original post link

Uh, this indeed shouldn’t happen. You can go ahead and file a bug… At least from what I see in the 7.0 documentation, OOM is still 8001.

| username: Billmay表妹 | Original post link

Can other partners reproduce it?

| username: 人如其名 | Original post link

Check the logs, it shows 8001. But the client always receives 1105 (unknown).
TiDB follows MySQL’s error code rules, categorizing its own error codes into MySQL’s standard error codes where possible, and those that can’t be categorized are placed under unknown. TiDB itself hasn’t extended these error codes, possibly considering client compatibility issues?

| username: TiDBer_ySLWWMGO | Original post link

Just find a large table and operate on it.

| username: TiDBer_ySLWWMGO | Original post link

It’s possible.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.