1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
#
# Bug #30258536 DEADLOCK BETWEEN LOB::ALLOC_LOB_PAGE AND ROW_UNDO_MOD_CLUST_LOW
#
# This scenario is for regression caused by fix for
# Bug #30178056 .IBD FILE GROWS INDEFINITELY FOR TABLES WITH BLOB COLUMNS
# which introduced an operation which latches first page during ROLLBACK,
# that leads to a failure of the assertion introduced in
# Bug #27777959 INNODB: ASSERTION FAILURE: UT0UT.CC DUE TO DEADLOCK AT FSP_PAGE_CREATE()
# which states that the first page of zLOB should not be latched during lob::z_rollback.
# This test demonstrates that it is not sufficient to simply remove the failing assert
# from code, as then the server will deadlock when the thread which ROLLBACKs tries
# to latch space to reserve pages, holding the latch on zLOB's freed first page, while
# the thread doing INSERT tries to latch the freed page, while holding space latch.
#
# This scenario is somewhat similar to innodb.lob_rollback_deadlock, differing by:
# - uses FORMAT=compressed
# - uses different lengths of blobs to arrange for a particular situation
# - modifies the zBLOB from very short (which fits inline) to very long
# (which requires indexing) and then rollsback
--source include/have_debug_sync.inc
--source include/have_innodb_16k.inc
--source include/count_sessions.inc
SET GLOBAL innodb_compression_level = 0;
CREATE TABLESPACE ts1 FILE_BLOCK_SIZE=8K;
CREATE TABLE t1 (
id INT PRIMARY KEY,
make_big CHAR(200),
val LONGBLOB
) ROW_FORMAT=compressed TABLESPACE ts1;
CREATE TABLE t2 (
id INT PRIMARY KEY,
make_big CHAR(200),
val LONGBLOB
) ROW_FORMAT=compressed TABLESPACE ts1;
INSERT INTO t2 (id,val) VALUES (1,REPEAT('a',1000000));
INSERT INTO t1 (id,val) VALUES (2,REPEAT('a',1000000));
INSERT INTO t2 (id,val) VALUES (2,REPEAT('a',1000000));
INSERT INTO t1 (id,val) VALUES (3,REPEAT('a',1000000));
# Length of the following blobs is chosen in such a way, that the
# first page of the LOB which we will allocate by the following UPDATE t2
# will be first page of an extent, and therefore, the rollback of the
# UPDATE will free the extent and make it available for the following
# INSERT INTO t1.
# We need a very short blob (here: 13 chars) so that it fits inline.
INSERT INTO t2 (id,val) VALUES (3,REPEAT('a',312000));
INSERT INTO t2 (id,val) VALUES (4,REPEAT('a',13));
--connect (con1,localhost,root,,)
--connect (con2,localhost,root,,)
--connection con1
BEGIN;
UPDATE t2 SET val = REPEAT('b',1000000) WHERE id=4;
SET DEBUG_SYNC=
'ib_blob_update_rollback_will_reserve
SIGNAL con1_will_reserve
WAIT_FOR con1_can_reserve';
--send ROLLBACK
--connection default
SET DEBUG_SYNC='now WAIT_FOR con1_will_reserve';
--connection con2
BEGIN;
--send INSERT INTO t1 (id,val) VALUES (4000,REPEAT('b',10000000))
--connection default
# I am sorry about this sleep. What we really wait for is a
# call to buf_page_get_gen with page_no equal to the page
# which was previously freed by the ROLLBACK of UPDATE.
# It's not easy to hard code this, and there are multiple
# calls to buf_page_get_gen() before it happens.
--sleep 1
SET DEBUG_SYNC='now SIGNAL con1_can_reserve';
--connection con1
--reap
--connection con2
--reap
ROLLBACK;
--connection default
--disconnect con1
--disconnect con2
DROP TABLE t1;
DROP TABLE t2;
DROP TABLESPACE ts1;
SET GLOBAL innodb_compression_level = default;
--source include/wait_until_count_sessions.inc
|
