pingcap / pingcap/tidb

txn: read information.tables do not start a txn when auto_commit is false

Open
#57,321 1 comment 0 reactions 0 assignees View on GitHub
affects-6.5 report/customer sig/transaction type/bug type/compatibility
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
open two session, and set auto_commit=false
![H4n1uJW9BI](https://github.com/user-attachments/assets/9ed2c20d-572f-4293-a215-86dcdc7555e6)

here t1 < t2< t3

### 2. What did you expect to see? (Required)
here I expect t3 could not get data id=1, which means t1 and t3 should be in one transaction

### 3. What did you see instead (Required)

t1 and t3 are not in one transaction

### 4. What is your TiDB version? (Required)
v7.5.2

Meanwhile, I have tested mysql 8.2, t1 and t3 are in the same transaction.
and it seems caused by tidb do not read data from tikv when `select * from information_schema.tables` while mysql would read data from storage for this case

```
mysql> explain select * from information_schema.tables;
+----------------+----------+------+---------------+---------------+
| id | estRows | task | access object | operator info |
+----------------+----------+------+---------------+---------------+
| MemTableScan_4 | 10000.00 | root | table:TABLES | |
+----------------+----------+------+---------------+---------------+
1 row in set (0.00 sec)

```
In other words, for tidb, when auto_commit = false, transactions will not be started when encountering SQL that is not read or written from tikv.
Although this meets expectations, it is inconsistent with the behavior of MySQL. should we adjust TiDB's behavior to be consistent with MySQL for this case?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.