Bug #95070 | INSERT .. VALUES ( .., (SELECT ..), ..) takes shared lock with READ-COMMITTED | ||
---|---|---|---|
Submitted: | 20 Apr 2019 14:07 | Modified: | 2 May 2019 13:09 |
Reporter: | Seunguck Lee | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 8.0.15 | OS: | Any |
Assigned to: | CPU Architecture: | x86 |
[20 Apr 2019 14:07]
Seunguck Lee
[24 Apr 2019 13:31]
MySQL Verification Team
Hi Mr. Lee, It is difficult to understand what makes you believe that the locks which cause the timeout are on the table that you select from (t1) as opposed to the table you insert to (tab). We have tried to run the same queries, assuming that t1 is prepared by : create table t1 (id int not null primary key, balance int not null); insert into t1 values (1,10),(2,-10),(3,20),(4,50); and the locks just after the first session executes are: mysql> select engine_transaction_id, object_name, index_name, lock_type, lock_mode, lock_status, lock_data from performance_schema.data_locks; +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ | engine_transaction_id | object_name | index_name | lock_type | lock_mode | lock_status | lock_data | +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ | 21800 | tab | NULL | TABLE | IS | GRANTED | NULL | | 21800 | tab | PRIMARY | RECORD | S,REC_NOT_GAP | GRANTED | 2 | | 21800 | tab | NULL | TABLE | IX | GRANTED | NULL | +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ 3 rows in set (0.00 sec) and after the second session starts waiting: mysql> select engine_transaction_id, object_name, index_name, lock_type, lock_mode, lock_status, lock_data from performance_schema.data_locks; +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ | engine_transaction_id | object_name | index_name | lock_type | lock_mode | lock_status | lock_data | +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ | 21800 | tab | NULL | TABLE | IS | GRANTED | NULL | | 21800 | tab | PRIMARY | RECORD | S,REC_NOT_GAP | GRANTED | 2 | | 21800 | tab | NULL | TABLE | IX | GRANTED | NULL | | 21800 | tab | PRIMARY | RECORD | X,REC_NOT_GAP | GRANTED | 3 | | 283279405915496 | tab | NULL | TABLE | IS | GRANTED | NULL | | 283279405915496 | tab | PRIMARY | RECORD | S,REC_NOT_GAP | WAITING | 3 | +-----------------------+-------------+------------+-----------+---------------+-------------+-----------+ 6 rows in set (0.00 sec) Hence, please, let us know why do you believe this is a lock on t1 that you are waiting for ??? Many thanks in advance.
[26 Apr 2019 2:10]
Seunguck Lee
Hi. >> It is difficult to understand what makes you believe that the locks which cause the timeout are on the table that you select from (t1) as opposed to the table you insert to (tab). Sorry. it's my mistake. There's only one table is used, just change the table name from 't1' to 'tab'.
[26 Apr 2019 2:15]
Seunguck Lee
Sorry for confused comment. (Just forget about my previous comment) Actually no problem on my repeat scenario. "t1" you have mentioned is just alias for "tab" table in subquery.
[2 May 2019 13:09]
MySQL Verification Team
Thank you for your feedback.