[MDEV-6063] overlocking next-record in REPEATABLE-READ with delete from where x <= num Created: 2014-04-10 Updated: 2014-04-11 Resolved: 2014-04-11 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 5.1.67, 5.2.14, 5.3.12, 5.5.36, 10.0.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Daniel Black | Assignee: | Jan Lindström (Inactive) |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | upstream | ||
| Issue Links: |
|
||||||||
| Description |
|
(from maria-discuss list) Why tx_isolation=REPEATABLE-READ should have a next-record lock on record 3 rather than a record lock? SESSION 1:
SESSION 2:
And it works in READ-COMMITTED SESSION 1:
SESSION 2:
|
| Comments |
| Comment by Jan Lindström (Inactive) [ 2014-04-11 ] |
|
Hi, this is desired behavior. For repeatable read we need keep result set consistent i.e. it should remain as 1,2,3 on duration of transaction doing a delete. Thus there should not be possible to insert (0) and currently there is no knowledge that something like (1.5) is not possible. Similarly, in multi-key primary keys it is not trivial to find out if <= key and the first matching row y are the same i.e. is y == key, thus we need to protect possible insert after first matchiing key => take gap lock after (3). In example case we know that next possible value is (4) and thus there is no real need to have gap lock between (3) and (4). Lets assume this same table and same data but delete with <= 8, here we would need gap lock to avoid insert with any of the possible values 4--8. Thus, theoretically we could avoid unnecessary gap locks if we have unique not null primary key consisting only simple data types and the first matching key would match perfectilely to search key and search key would use this primary key. Therefore, only in very limited cases there is real possible room for improvement and in my opinion the time to check if we are hitting one of the limited cases takes more time than (in overral, because this would effect every gap lock request) what we would really save. |
| Comment by Daniel Black [ 2014-04-11 ] |
|
thank you for the detailed explanation. |