mirror of
https://github.com/MariaDB/server.git
synced 2025-10-31 19:06:14 +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.
29 lines
800 B
Text
29 lines
800 B
Text
--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;
|