Bug #105988 The problem about predicate lock in Serializable isolation level
Submitted: 28 Dec 2021 7:22 Modified: 11 Jan 2022 14:09
Reporter: Siyang Weng Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.7.27/8.0.27 OS:Red Hat (Red Hat 4.8.5-39)
Assigned to: CPU Architecture:x86 (3.10.0-1127.10.1.el7.x86_64)

[28 Dec 2021 7:22] Siyang Weng
Description:
We found that the behaviours among some queries are not allowed under serializable isolation.The general logs related with this problem are shown below:
Time                 Id Command    Argument
2021-12-28T02:47:05.312374Z	69264 Query	SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
2021-12-28T02:47:05.312370Z	69269 Query	SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
-- System executes other queries and the isolation level in 69269 remains unchanged.  ...
2021-12-28T02:47:05.847549Z	69264 Query	START TRANSACTION
2021-12-28T02:47:05.848042Z	69264 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(225, 225, 35704) -- Transaction 69264 inserts record into table0 where pkAttr0 = 225
2021-12-28T02:47:05.848605Z	69264 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(275, 275, 5522)
2021-12-28T02:47:05.849171Z	69264 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(453, 453, 97530)
2021-12-28T02:47:05.855935Z	69269 Query	START TRANSACTION
2021-12-28T02:47:05.856202Z	69269 Execute	select `pkAttr0`, `coAttr0_0` from `table0` where ( `pkAttr0` = 1488 )
2021-12-28T02:47:05.856621Z	69269 Execute	select `pkAttr0`, `coAttr0_0` from `table0` where ( `pkAttr0` = 225 )-- Unexpected!This query should be blocked untill the transaction  69264 rollbacked.
2021-12-28T02:47:05.951072Z	69269 Execute	select `pkAttr0`, `coAttr0_0` from `table0` where ( `pkAttr0` = 680 )
2021-12-28T02:47:05.951142Z	69264 Query	rollback

How to repeat:
We share all general log in this Github repository https://github.com/wengsy150943/bug_report_attachment/tree/main/mysql/5.7-001 .
[28 Dec 2021 7:29] Siyang Weng
The schema is: create table table0 (pkId integer, pkAttr0 integer, coAttr0_0 integer, primary key(pkAttr0));
[31 Dec 2021 6:32] Siyang Weng
The similar problem can also be found in version 8.0.27.

The schema is: create table table0 (pkId integer, pkAttr0 integer, coAttr0_0 integer, primary key(pkAttr0))

The general logs related with this problem are shown below:
Time                 Id Command    Argument
2021-12-30T05:41:11.592577Z	 8278 Query	SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
2021-12-30T05:41:11.592529Z	 8273 Query	SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
-- System executes other queries and the isolation level in 8278 remains unchanged.  ...
2021-12-30T05:41:12.498916Z	 8278 Query	START TRANSACTION
2021-12-30T05:41:12.499661Z	 8278 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(91, 91, 48959)
2021-12-30T05:41:12.500518Z	 8278 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(1040, 1040, 60781)
2021-12-30T05:41:12.502026Z	 8278 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(403, 403, 42217)
2021-12-30T05:41:12.503111Z	 8278 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(408, 408, 22650) -- Transaction 8278 inserts record into table0 where pkAttr0 = 225
2021-12-30T05:41:12.559220Z	 8273 Query	START TRANSACTION
2021-12-30T05:41:12.559950Z	 8273 Execute	select `pkAttr0`, `coAttr0_0` from `table0` where ( `pkAttr0` = 408 ) -- Unexpected!This query should be blocked untill the transaction  8278 rollbacked.
2021-12-30T05:41:12.504601Z	 8278 Execute	insert into `table0`(`pkId`, `pkAttr0`, `coAttr0_0`) values(452, 452, 2684)
2021-12-30T05:41:12.720278Z	 8278 Query	rollback

We share all general log in this Github repository https://github.com/wengsy150943/bug_report_attachment/tree/main/mysql/8.0-001 .
[10 Jan 2022 14:55] MySQL Verification Team
Hi Mr. Weng,

Thank you for your bug report.

However, this does not seem to be a bug. But, we have to check it out.

Make sure that first transaction is finished and then, only then you start second transaction. It is also very important for us to know whether autocommit is ON or OFF. 

It is important to note that this isolation level behaves like REPEATABLE READ, only with added locks.

Last, but not least, try not to use brackets around the expressions when those are not needed.
[11 Jan 2022 6:36] Siyang Weng
Thanks for your response! 

As you mentioned, we have confirmed that these two transactions overlap and both of these transactions' autocommit is OFF.

Taking the above case in MySQL 8.0.27 as an example, transaction 8278 start at 2021-12-30T05:41:12.498916Z(Line 5972) and end at 2021-12-30T05:41:12.720278Z with a rollback(Line 6283). However, transaction 8273 has a select query executed at 2021-12-30T05:41:12.559950Z(Line 6158), which read the same data of transaction 8278. We also check that both of these transactions' autocommit is OFF(transaction 8278 at Line 4096 and transaction 8273 at Line 4103).
[11 Jan 2022 14:09] MySQL Verification Team
Hi Mr. Weng,

Actually, this isolation level works just fine with 8.0.27.

SELECT query hangs !!!!!! Here it is:

mysql> select `pkAttr0`, `coAttr0_0` from `table0` where ( `pkAttr0` = 408 );

There is no OK and no nothing ....... just hanging ...... when I commit first transaction, it runs .......

Can't repeat.