An immediate read after two UPDATE transactions does not pick up the change in the other transaction #15716

yanmingcao · 2020-03-26T06:53:43Z

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. What did you do?

I run the following script which consists of two transactions. After both transactions commit, a first SELECT cannot see the UPDATE by the other session. However if I run the same SELECT again, it picks up the UPDATE by the other session.

create table test (id int primary key, value int);
insert into test (id, value) values (1, 10), (2, 20);

begin; -- T1
begin; -- T2

update test set value = 11 where id = 1; -- T1
update test set value = 19 where id = 2; -- T1
update test set value = 12 where id = 1; -- T2. Blocked
commit; -- T1. This unblocks T2
update test set value = 18 where id = 2; -- T2
commit; -- T2

select * from test; -- T1. Shows 1 => 11, 2 => 19 (caching problem?)
select * from test; -- T1. Shows 1 => 12, 2 => 18 (correct result)

2. What did you expect to see?

The last two SELECT should return same result.

3. What did you see instead?

The next to last SELECT returns a result that does not reflect the change by T2.

4. What version of TiDB are you using? (`tidb-server -V` or run `select tidb_version();` on TiDB)

v3.0.12

The text was updated successfully, but these errors were encountered:

qw4990 · 2020-03-26T12:40:01Z

@yanmingcao Thanks for your feedback, but I can't reproduce your problem on my computer.
Actually the default transaction model of TiDB is optimistic, so the expected behaviors should be:

create table test (id int primary key, value int);
insert into test (id, value) values (1, 10), (2, 20);

begin; -- T1
begin; -- T2

update test set value = 11 where id = 1; -- T1
update test set value = 19 where id = 2; -- T1
update test set value = 12 where id = 1; -- T2: non-blocked since it is optimistic transaction model
commit; -- T1
update test set value = 18 where id = 2; -- T2
commit; -- T2: write conflict and then roll it back <<<

select * from test; -- T1. Shows 1 => 11, 2 => 19 
select * from test; -- T1. Shows 1 => 12, 2 => 19

Could you please check your operation again? And if there are still some problems, please @ me and give us more information.

yanmingcao · 2020-03-27T06:24:01Z

@qw4990 Thanks for looking into it. The script is not quite correct. The two transactions should be in pessimistic mode:

begin  pessimistic; -- T1
begin  pessimistic; -- T2

By the way, I found something strange about transaction mode.

begin optimistic;
select @@tidb_txn_mode; -- Shows "pessimistic"
commit

zz-jason · 2020-03-29T12:24:24Z

@coocood @tiancaiamao PTAL

coocood · 2020-03-29T12:53:10Z

@yanmingcao
Thank you for the feedback.

How the queries are executed? (terminal or application)
Does it produce the same result every time?

Is it possible that the start time of first select * from test; from T1 before the finish time of commit of T2?

yanmingcao · 2020-03-29T13:31:44Z

@coocood

I use two mysqlsh shells on my Windows laptop. One shell runs T1 and the other shell runs T2.

The TiDB environment was set up using docker-compose up -d.

T2 has been commited before the last two SELECT sql.

coocood · 2020-03-29T14:36:41Z

@yanmingcao
Does the first select always return the stale result?

yanmingcao · 2020-03-30T02:22:28Z

@coocood
Yes. Below is a simpler case to demostrate the issue:

select * from test; -- T1. Shows 1 => 10
update test set value = 11 where id = 1; -- T2
select * from test; -- T1. Shows 1 => 10 (caching problem?)
select * from test; -- T1. Shows 1 => 11 (correct result)

coocood · 2020-03-30T03:14:24Z

@yanmingcao
I can not reproduce this issue in my environment.
Have you changed any config or global variable?

yanmingcao · 2020-03-30T03:23:56Z

@coocood

I use tidb-docker-compose project to set up the docker environment, and I use mysqlsh shell to run the tests.

However I do see some strange thing about this enviroment. When I run select @@tidb_txn_mode; or select @@global.tidb_txn_mode;, it shows pessimistic. Should the default be optimistic?

coocood · 2020-03-30T03:30:41Z

@yanmingcao
The default is pessimistic if the cluster is newly created.

I tested with tidb-docker-compose on my Mac, can't reproduce the issue.
Maybe it has something to do with Windows or mysqlsh.

coocood · 2020-03-30T03:31:38Z

@jackysp PTAL

jackysp · 2020-03-30T03:48:25Z

@yanmingcao I can not reproduce it by using mysqlsh like mysqlsh --sqlc [email protected]:4000/test.

coocood · 2020-03-30T07:35:47Z

@yanmingcao
Can you execute set @@tidb_general_log = 1 to make TiDB log every query, and then collect the log for those queries?

yanmingcao · 2020-03-30T08:43:51Z

@coocood

It seems set @@tidb_general_log = 1 does not take effect. The tidb.log file does not contain any SQL query I executed.

By the way, in docker-compose.yml, I only run pd, tidb, and tikv instances. Not sure whether this is the cause.

coocood · 2020-03-30T09:00:35Z

It seems set @@tidb_general_log = 1 does not take effect. The tidb.log file does not contain any SQL query I executed.

Maybe the log file is not the right one?

By the way, in docker-compose.yml, I only run pd, tidb, and tikv instances. Not sure whether this is the cause.

No, it's not related.

tiancaiamao · 2020-03-31T03:56:24Z

Can not reproduce +1

Did you use this order? @yanmingcao

create table test (id int primary key, value int);
insert into test (id, value) values (1, 10), (2, 20);

begin; -- T1
begin; -- T2

update test set value = 11 where id = 1; -- T1
update test set value = 19 where id = 2; -- T1
update test set value = 12 where id = 1; -- T2. Blocked
commit; -- T1. This unblocks T2
update test set value = 18 where id = 2; -- T2

select * from test; -- T1. Shows 1 => 11, 2 => 19 (not a problem)
commit; -- T2

select * from test; -- T1. Shows 1 => 12, 2 => 18 (correct result)

yanmingcao · 2020-03-31T12:07:52Z

@coocood

I wonder why the queries are not logged into tidb.log. Is there any other log?

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        2020/3/30     16:34          45875 pd0.log
-a----        2020/3/30     16:35          48512 pd1.log
-a----        2020/3/30     16:34          46019 pd2.log
-a----        2020/3/30     16:34         105196 tidb.log
-a----        2020/3/30     16:34          25160 tikv0.log
-a----        2020/3/30     16:34          25015 tikv1.log
-a----        2020/3/30     16:34          25305 tikv2.log

yanmingcao · 2020-03-31T12:13:59Z

@tiancaiamao

No. I committed two transactions before running the select queries.

Did you try this on Windows 10? The version of mysqlsh is:

mysqlsh.exe   Ver 8.0.16 for Windows on AMD64 - for MySQL 8.0.16 (MySQL Community Server (GPL))

coocood · 2020-03-31T12:14:20Z

@yanmingcao

Please post the result of select @@tidb_general_log;

yanmingcao · 2020-03-31T12:51:24Z

@coocood

 MySQL  127.0.0.1:4000  test  SQL > select @@tidb_general_log;
+--------------------+
| @@tidb_general_log |
+--------------------+
| 1                  |
+--------------------+
1 row in set (0.0019 sec)

yanmingcao · 2020-03-31T12:54:29Z

@coocood

 MySQL  127.0.0.1:4000  test  SQL > drop table test;create table test (id int primary key, value int);insert into test (id, value) values (1, 10), (2, 20);select * from test;
Query OK, 0 rows affected (0.1266 sec)
Query OK, 0 rows affected (0.1009 sec)
Query OK, 2 rows affected (0.0244 sec)

Records: 2  Duplicates: 0  Warnings: 0
+----+-------+
| id | value |
+----+-------+
|  1 |    10 |
|  2 |    20 |
+----+-------+
2 rows in set (0.0035 sec)

 MySQL  127.0.0.1:4000  test  SQL > begin pessimistic; -- T1
Query OK, 0 rows affected (0.0023 sec)
Query OK, 0 rows affected (0.0024 sec)

 MySQL  127.0.0.1:4000  test  SQL > update test set value = 11 where id = 1; -- T1
Query OK, 1 row affected (0.0141 sec)

Rows matched: 1  Changed: 1  Warnings: 0
Query OK, 1 row affected (0.0024 sec)

Rows matched: 1  Changed: 1  Warnings: 0

 MySQL  127.0.0.1:4000  test  SQL > update test set value = 19 where id = 2; -- T1
Query OK, 1 row affected (0.0073 sec)

Rows matched: 1  Changed: 1  Warnings: 0
Query OK, 1 row affected (0.0016 sec)

Rows matched: 1  Changed: 1  Warnings: 0

 MySQL  127.0.0.1:4000  test  SQL > commit; -- T1. This unblocks T2
Query OK, 0 rows affected (0.0088 sec)
Query OK, 0 rows affected (0.0012 sec)

 MySQL  127.0.0.1:4000  test  SQL > select * from test; -- T1. Shows 1 => 11, 2 => 19 (caching problem?)
+----+-------+
| id | value |
+----+-------+
|  1 |    11 |
|  2 |    19 |
+----+-------+
2 rows in set (0.0029 sec)
Query OK, 0 rows affected (0.0012 sec)

 MySQL  127.0.0.1:4000  test  SQL > select * from test; -- T1. Shows 1 => 12, 2 => 18 (correct result)
+----+-------+
| id | value |
+----+-------+
|  1 |    12 |
|  2 |    18 |
+----+-------+
2 rows in set (0.0030 sec)
Query OK, 0 rows affected (0.0031 sec)

coocood · 2020-03-31T14:21:44Z

@yanmingcao
Why one statements show two results?

 MySQL  127.0.0.1:4000  test  SQL > commit; -- T1. This unblocks T2
Query OK, 0 rows affected (0.0088 sec)
Query OK, 0 rows affected (0.0012 sec)

coocood · 2020-03-31T14:43:21Z

@yanmingcao
Would you please replace the

select * from test;

with

select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;

And try again

yanmingcao · 2020-04-01T00:20:28Z

@coocood

The result for your request is below:

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+-------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts | CONNECTION_ID() |
+----+-------+----------------------------+-------------------+-----------------+
|  1 |    11 | 2020-03-31 23:56:35.393446 | 0                 |               2 |
|  2 |    19 | 2020-03-31 23:56:35.393446 | 0                 |               2 |
+----+-------+----------------------------+-------------------+-----------------+
2 rows in set (0.0032 sec)

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+-------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts | CONNECTION_ID() |
+----+-------+----------------------------+-------------------+-----------------+
|  1 |    12 | 2020-03-31 23:56:39.577420 | 0                 |               2 |
|  2 |    18 | 2020-03-31 23:56:39.577420 | 0                 |               2 |
+----+-------+----------------------------+-------------------+-----------------+
2 rows in set (0.0026 sec)

coocood · 2020-04-01T01:21:09Z

@yanmingcao

Thank you, please replace the T2 commit; statement with:

commit;select *, now(), @@tidb_current_ts, connection_id() from test;

and post the result, along with the T1's result of

select *, now(), @@tidb_current_ts, connection_id() from test;

yanmingcao · 2020-04-01T01:42:32Z

@coocood

From T2:

 MySQL  127.0.0.1:4000  test  SQL > commit; select *, now(), @@tidb_current_ts, connection_id() from test;
Query OK, 0 rows affected (0.0135 sec)
+----+-------+---------------------+-------------------+-----------------+
| id | value | now()               | @@tidb_current_ts | connection_id() |
+----+-------+---------------------+-------------------+-----------------+
|  1 |    12 | 2020-04-01 01:27:31 | 0                 |               4 |
|  2 |    18 | 2020-04-01 01:27:31 | 0                 |               4 |
+----+-------+---------------------+-------------------+-----------------+
2 rows in set (0.0035 sec)

From T1:

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+-------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts | CONNECTION_ID() |
+----+-------+----------------------------+-------------------+-----------------+
|  1 |    11 | 2020-04-01 01:27:40.065282 | 0                 |               2 |
|  2 |    19 | 2020-04-01 01:27:40.065282 | 0                 |               2 |
+----+-------+----------------------------+-------------------+-----------------+
2 rows in set (0.0021 sec)

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+-------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts | CONNECTION_ID() |
+----+-------+----------------------------+-------------------+-----------------+
|  1 |    12 | 2020-04-01 01:27:41.312471 | 0                 |               2 |
|  2 |    18 | 2020-04-01 01:27:41.312471 | 0                 |               2 |
+----+-------+----------------------------+-------------------+-----------------+
2 rows in set (0.0031 sec)

coocood · 2020-04-01T02:39:22Z

@yanmingcao
It's very strange, we don't have any cache for query results.
And we have many tests that would fail if we read stale results.

Now it seems that it has nothing to do with mysqlsh or Windows.

Another two things may help address this issue.

please post the result of select @@tidb_config;
Try execute begin; on T1 before the last two select statements and post the result.

Thank you!

yanmingcao · 2020-04-01T02:59:53Z

@coocood

Result of select @@tidb_config;

 {
        "host": "0.0.0.0",
        "advertise-address": "tidb",
        "port": 4000,
        "cors": "",
        "store": "tikv",
        "path": "pd0:2379,pd1:2379,pd2:2379",
        "socket": "",
        "lease": "0",
        "run-ddl": true,
        "split-table": true,
        "token-limit": 1000,
        "oom-action": "log",
        "mem-quota-query": 34359738368,
        "enable-streaming": false,
        "enable-batch-dml": false,
        "txn-local-latches": {
                "enabled": false,
                "capacity": 2048000
        },
        "lower-case-table-names": 2,
        "server-version": "",
        "log": {
                "level": "error",
                "format": "text",
                "disable-timestamp": false,
                "file": {
                        "filename": "/logs/tidb.log",
                        "log-rotate": true,
                        "max-size": 300,
                        "max-days": 0,
                        "max-backups": 0
                },
                "slow-query-file": "",
                "slow-threshold": 300,
                "expensive-threshold": 10000,
                "query-log-max-len": 2048,
                "record-plan-in-slow-log": 1
        },
        "security": {
                "skip-grant-table": false,
                "ssl-ca": "",
                "ssl-cert": "",
                "ssl-key": "",
                "cluster-ssl-ca": "",
                "cluster-ssl-cert": "",
                "cluster-ssl-key": "",
                "cluster-verify-cn": null
        },
        "status": {
                "report-status": true,
                "status-host": "0.0.0.0",
                "status-port": 10080,
                "metrics-addr": "pushgateway:9091",
                "metrics-interval": 15,
                "record-db-qps": false
        },
        "performance": {
                "max-procs": 0,
                "max-memory": 0,
                "tcp-keep-alive": true,
                "cross-join": true,
                "stats-lease": "3s",
                "run-auto-analyze": true,
                "stmt-count-limit": 5000,
                "feedback-probability": 0,
                "query-feedback-limit": 1024,
                "pseudo-estimate-ratio": 0.7,
                "force-priority": "NO_PRIORITY",
                "bind-info-lease": "3s",
                "txn-entry-count-limit": 300000,
                "txn-total-size-limit": 104857600
        },
        "prepared-plan-cache": {
                "enabled": false,
                "capacity": 100,
                "memory-guard-ratio": 0.1
        },
        "opentracing": {
                "enable": false,
                "sampler": {
                        "type": "const",
                        "param": 1,
                        "sampling-server-url": "",
                        "max-operations": 0,
                        "sampling-refresh-interval": 0
                },
                "reporter": {
                        "queue-size": 0,
                        "buffer-flush-interval": 0,
                        "log-spans": false,
                        "local-agent-host-port": ""
                },
                "rpc-metrics": false
        },
        "proxy-protocol": {
                "networks": "",
                "header-timeout": 5
        },
        "tikv-client": {
                "grpc-connection-count": 16,
                "grpc-keepalive-time": 10,
                "grpc-keepalive-timeout": 3,
                "commit-timeout": "41s",
                "max-txn-time-use": 590,
                "max-batch-size": 128,
                "overload-threshold": 200,
                "max-batch-wait-time": 0,
                "batch-wait-size": 8,
                "region-cache-ttl": 600,
                "store-limit": 0
        },
        "binlog": {
                "enable": false,
                "write-timeout": "15s",
                "ignore-error": false,
                "binlog-socket": "",
                "strategy": "range"
        },
        "compatible-kill-query": false,
        "plugin": {
                "dir": "",
                "load": ""
        },
        "pessimistic-txn": {
                "enable": true,
                "max-retry-count": 256
        },
        "check-mb4-value-in-utf8": true,
        "max-index-length": 3072,
        "alter-primary-key": false,
        "treat-old-version-utf8-as-utf8mb4": true,
        "split-region-max-num": 1000,
        "stmt-summary": {
                "enable": false,
                "max-stmt-count": 200,
                "max-sql-length": 4096,
                "refresh-interval": 1800,
                "history-size": 24
        }
}

With begin; before the two select :

 MySQL  127.0.0.1:4000  test  SQL > begin;
Query OK, 0 rows affected (0.0036 sec)

 MySQL  127.0.0.1:4000  test  SQL > select * from test; -- T1. Shows 1 => 11, 2 => 19 (caching problem?)
+----+-------+
| id | value |
+----+-------+
|  1 |    11 |
|  2 |    19 |
+----+-------+
2 rows in set (0.0071 sec)
Query OK, 0 rows affected (0.0015 sec)

 MySQL  127.0.0.1:4000  test  SQL > select * from test; -- T1. Shows 1 => 11, 2 => 19 (caching problem?)
+----+-------+
| id | value |
+----+-------+
|  1 |    11 |
|  2 |    19 |
+----+-------+
2 rows in set (0.0027 sec)
Query OK, 0 rows affected (0.0016 sec)

 MySQL  127.0.0.1:4000  test  SQL > commit;
Query OK, 0 rows affected (0.0025 sec)

 MySQL  127.0.0.1:4000  test  SQL > select * from test;-- T1. Shows 1 => 11, 2 => 19 (caching problem?)
+----+-------+
| id | value |
+----+-------+
|  1 |    12 |
|  2 |    18 |
+----+-------+
2 rows in set (0.0058 sec)
Query OK, 0 rows affected (0.0044 sec)

coocood · 2020-04-01T03:20:33Z

@yanmingcao
Thank you!
The config is normal.
The select after begin should be select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;

coocood · 2020-04-01T03:33:19Z

By the way, please change the previous

commit; select *, now(), @@tidb_current_ts, connection_id() from test;`

on T2, to

commit; begin; select *, now(), @@tidb_current_ts, connection_id() from test;

yanmingcao · 2020-04-01T03:49:14Z

@coocood

From T2:

 MySQL  127.0.0.1:4000  test  SQL > commit; begin; select *, now(), @@tidb_current_ts, connection_id() from test;
Query OK, 0 rows affected (0.0312 sec)
Query OK, 0 rows affected (0.0062 sec)
+----+-------+---------------------+--------------------+-----------------+
| id | value | now()               | @@tidb_current_ts  | connection_id() |
+----+-------+---------------------+--------------------+-----------------+
|  1 |    12 | 2020-04-01 03:44:19 | 415685059323625473 |               4 |
|  2 |    18 | 2020-04-01 03:44:19 | 415685059323625473 |               4 |
+----+-------+---------------------+--------------------+-----------------+
2 rows in set (0.0178 sec)

From T1:

 MySQL  127.0.0.1:4000  test  SQL > begin;
Query OK, 0 rows affected (0.0026 sec)

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+--------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts  | CONNECTION_ID() |
+----+-------+----------------------------+--------------------+-----------------+
|  1 |    11 | 2020-04-01 03:44:33.407886 | 415685054290722820 |               2 |
|  2 |    19 | 2020-04-01 03:44:33.407886 | 415685054290722820 |               2 |
+----+-------+----------------------------+--------------------+-----------------+
2 rows in set (0.0034 sec)

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+--------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts  | CONNECTION_ID() |
+----+-------+----------------------------+--------------------+-----------------+
|  1 |    11 | 2020-04-01 03:44:35.871744 | 415685054290722820 |               2 |
|  2 |    19 | 2020-04-01 03:44:35.871744 | 415685054290722820 |               2 |
+----+-------+----------------------------+--------------------+-----------------+
2 rows in set (0.0035 sec)

 MySQL  127.0.0.1:4000  test  SQL > commit;
Query OK, 0 rows affected (0.0118 sec)

 MySQL  127.0.0.1:4000  test  SQL > select *, now(6), @@tidb_current_ts, CONNECTION_ID() from test;
+----+-------+----------------------------+-------------------+-----------------+
| id | value | now(6)                     | @@tidb_current_ts | CONNECTION_ID() |
+----+-------+----------------------------+-------------------+-----------------+
|  1 |    12 | 2020-04-01 03:44:41.278819 | 0                 |               2 |
|  2 |    18 | 2020-04-01 03:44:41.278819 | 0                 |               2 |
+----+-------+----------------------------+-------------------+-----------------+
2 rows in set (0.0035 sec)

coocood · 2020-04-01T04:31:26Z

@yanmingcao
Thank you for your help, we will take some time trying to reproduce it.

jackysp · 2020-04-02T12:57:01Z

It seems that none of us can reproduce your issue, @yanmingcao . Do you have a WeChat account? If you don't mind, you can send your WeChat account to [email protected] and we can contact on WeChat.

jackysp · 2020-04-07T08:48:58Z

Sorry @yanmingcao , [email protected] did not previously have permission to receive out-of-company mail. If we missed your contact information, please send it again. Thank you!

yanmingcao · 2020-04-12T04:40:32Z

@jackysp I sent email to [email protected] twice. Not sure you got it.

jackysp · 2020-04-12T06:12:40Z

I've received it. Sorry for the late reply.

jackysp · 2020-04-13T13:44:08Z

Simple reproduction steps for MacOSX or Linux users:

tiup playground v3.0.12

create table t (i int);
insert into t values (1);

go run tidb.go

package main

import (
        "database/sql"
        "log"

        _ "github.com/go-sql-driver/mysql"
)

func main() {
        connStr := "root@tcp(127.0.0.1:38900)/test?charset=utf8mb4&parseTime=True&loc=Local"
        db, err := sql.Open("mysql", connStr)
        if err != nil {
                log.Fatal(err)
        }
        defer db.Close()

        db2, err := sql.Open("mysql", connStr)
        if err != nil {
                log.Fatal(err)
        }
        defer db2.Close()

        _, err = db.Exec("-- T1")
        if err != nil {
                log.Fatal(err)
        }

        _, err = db2.Exec( "update t set i = i + 1")
        if err != nil {
                log.Fatal(err)
        }

        for i := 0; i < 2; i++ {
                rows, err := db.Query("select * from t")
                if err != nil {
                        log.Fatal(err)
                }
                log.Println("time", i)
                var r int
                for rows.Next() {
                        if err := rows.Scan(&r); err != nil {
                                log.Fatal(err)
                        }
                        log.Println(r)
                }
        }
}

jackysp · 2020-04-15T04:39:35Z

Fixed by #16336 #16335 #16334

yanmingcao added the type/bug The issue is confirmed as a bug. label Mar 26, 2020

zz-jason added the priority/P1 The issue has P1 priority. label Mar 29, 2020

zz-jason added the sig/transaction SIG:Transaction label Mar 29, 2020

zz-jason assigned coocood Mar 30, 2020

lysu mentioned this issue Apr 13, 2020

session: invalid pending txn if it's a empty stmt #16325

Closed

jackysp modified the milestones: v3.0.13, v3.1.0-ga Apr 15, 2020

tiancaiamao closed this as completed Apr 16, 2020

sre-bot added the severity/critical label Aug 10, 2020

An immediate read after two UPDATE transactions does not pick up the change in the other transaction #15716

An immediate read after two UPDATE transactions does not pick up the change in the other transaction #15716

Comments

yanmingcao commented Mar 26, 2020

Bug Report

1. What did you do?

2. What did you expect to see?

3. What did you see instead?

4. What version of TiDB are you using? (tidb-server -V or run select tidb_version(); on TiDB)

qw4990 commented Mar 26, 2020

yanmingcao commented Mar 27, 2020

zz-jason commented Mar 29, 2020

coocood commented Mar 29, 2020

yanmingcao commented Mar 29, 2020

coocood commented Mar 29, 2020

yanmingcao commented Mar 30, 2020

coocood commented Mar 30, 2020

yanmingcao commented Mar 30, 2020

coocood commented Mar 30, 2020

coocood commented Mar 30, 2020

jackysp commented Mar 30, 2020

coocood commented Mar 30, 2020

yanmingcao commented Mar 30, 2020

coocood commented Mar 30, 2020

tiancaiamao commented Mar 31, 2020

yanmingcao commented Mar 31, 2020

yanmingcao commented Mar 31, 2020

coocood commented Mar 31, 2020

yanmingcao commented Mar 31, 2020

yanmingcao commented Mar 31, 2020

coocood commented Mar 31, 2020 • edited Loading

coocood commented Mar 31, 2020 • edited Loading

yanmingcao commented Apr 1, 2020

coocood commented Apr 1, 2020

yanmingcao commented Apr 1, 2020

coocood commented Apr 1, 2020

yanmingcao commented Apr 1, 2020

coocood commented Apr 1, 2020

coocood commented Apr 1, 2020

yanmingcao commented Apr 1, 2020

coocood commented Apr 1, 2020

jackysp commented Apr 2, 2020

jackysp commented Apr 7, 2020

yanmingcao commented Apr 12, 2020

jackysp commented Apr 12, 2020

jackysp commented Apr 13, 2020

jackysp commented Apr 15, 2020 • edited Loading

4. What version of TiDB are you using? (`tidb-server -V` or run `select tidb_version();` on TiDB)

coocood commented Mar 31, 2020 •

edited

Loading

coocood commented Mar 31, 2020 •

edited

Loading

jackysp commented Apr 15, 2020 •

edited

Loading