Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
13.1, 13.2
-
None
Description
Likely cause: MDEV-24813, commit 5a3d98a36cf31d2d886135afb27c483c4c5da82b, which added innodb_table_lock_on_full_scan in 13.1.1. This is not a regression, as the variable has had no effect on a partitioned table from the start.
--source include/have_innodb.inc
|
--source include/have_partition.inc
|
--source include/have_sequence.inc
|
CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB PARTITION BY HASH (a) PARTITIONS 4; |
INSERT INTO t1 SELECT seq, seq FROM seq_1_to_1000; |
SET SESSION innodb_table_lock_on_full_scan= ON; |
BEGIN; |
DELETE FROM t1; |
--sleep 0.3
|
--let $n= `SELECT trx_rows_locked FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID()`
|
ROLLBACK; |
if ($n) |
{
|
--die With innodb_table_lock_on_full_scan=ON a full scan of a partitioned InnoDB table still locks rows one by one ($n rows), no table lock |
}
|
SET SESSION innodb_table_lock_on_full_scan= DEFAULT; |
DROP TABLE t1; |
Leads to:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 05/10/2026 |
mysqltest: At line 14: With innodb_table_lock_on_full_scan=ON a full scan of a partitioned InnoDB table still locks rows one by one (1004 rows), no table lock
|
The DELETE locks 1004 rows, the same as with innodb_table_lock_on_full_scan=OFF. Without partitioning, it takes one table lock and locks no rows. UPDATE, SELECT ... FOR UPDATE and INSERT ... SELECT without a WHERE clause also lock each row of the partitioned table. Debug builds give the same result.
From the code it seems that ha_partition::extra_opt() returns 0 for HA_EXTRA_FULL_SCAN and does not pass it on to the partitions, so InnoDB does not take the table lock.
Attachments
Issue Links
- is caused by
-
MDEV-24813 Locking full table scan fails to use table-level locking
-
- Closed
-
- relates to
-
MDEV-41351 Redundant clustered lookups in covering scans when holding a table X-lock
-
- Closed
-