mirror of
https://github.com/MariaDB/server.git
synced 2025-04-26 11:49:09 +03:00
8047c8bc71
This regression is introduced in 10.6 by following commit. commit 898dcf93a886a68450dce7713208fdad82f9178e (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.
30 lines
800 B
Plaintext
30 lines
800 B
Plaintext
--source include/have_innodb.inc
|
|
--source include/have_innodb_16k.inc
|
|
|
|
--echo #
|
|
--echo # MDEV-28800 SIGABRT due to running out of memory for InnoDB locks
|
|
--echo #
|
|
|
|
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 64K records
|
|
INSERT INTO t1 SELECT a.* FROM t1 a, t1 b, t1 c, t1 d;
|
|
|
|
# The check needs to be adjusted if we start using more memory for locks. It
|
|
# needs 9 pages for 16k page size and we put the limit as 10.
|
|
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;
|
|
|
|
COMMIT;
|
|
|
|
SELECT COUNT(*) FROM t1;
|
|
|
|
DROP TABLE t1;
|