mirror of
https://github.com/MariaDB/server.git
synced 2025-01-30 18:41:56 +01:00
8047c8bc71
This regression is introduced in 10.6 by following commit.
commit 898dcf93a8
(Cleanup the lock creation)
It removed one important optimization for lock bitmap pre-allocation.
We pre-allocate about 8 byte extra space along with every lock object to
adjust for similar locks on newly created records on the same page by
same transaction. When it is exhausted, a new lock object is created
with similar 8 byte pre-allocation. With this optimization removed we
are left with only 1 byte pre-allocation. When large number of records
are inserted and locked in a single page, we end up creating too many
new locks almost in n^2 order.
Fix-1: Bring back LOCK_PAGE_BITMAP_MARGIN for pre-allocation.
Fix-2: Use the extra space (40 bytes) for bitmap in trx->lock.rec_pool.
20 lines
705 B
Text
20 lines
705 B
Text
#
|
|
# MDEV-28800 SIGABRT due to running out of memory for InnoDB locks
|
|
#
|
|
CREATE TABLE t1 (col1 INT) ENGINE=InnoDB;
|
|
INSERT INTO t1 VALUES (1),(2),(3),(4);
|
|
INSERT INTO t1 SELECT * FROM t1;
|
|
INSERT INTO t1 SELECT * FROM t1;
|
|
START TRANSACTION;
|
|
INSERT INTO t1 SELECT a.* FROM t1 a, t1 b, t1 c, t1 d;
|
|
SELECT CASE WHEN (POOL_SIZE - (FREE_BUFFERS + DATABASE_PAGES)) <= 10 THEN "PASSED"
|
|
ELSE (POOL_SIZE - (FREE_BUFFERS + DATABASE_PAGES)) END
|
|
FROM information_schema.innodb_buffer_pool_stats;
|
|
CASE WHEN (POOL_SIZE - (FREE_BUFFERS + DATABASE_PAGES)) <= 10 THEN "PASSED"
|
|
ELSE (POOL_SIZE - (FREE_BUFFERS + DATABASE_PAGES)) END
|
|
PASSED
|
|
COMMIT;
|
|
SELECT COUNT(*) FROM t1;
|
|
COUNT(*)
|
|
65552
|
|
DROP TABLE t1;
|