Details
- 
    
Bug
 - 
    Status: Closed (View Workflow)
 - 
    
Major
 - 
    Resolution: Fixed
 - 
    10.2(EOL)
 - 
    None
 
Description
In tests:
- main.lock_sync
 - main.innodb_mysql_sync
 - main.partition_debug_sync
 - innodb.auto_increment_dup
 
branch bb-10.2-jan commit 3f1b8c9474e351e50a6556675108864d5aac5528
Example:
					CURRENT_TEST: main.lock_sync
			 | 
		
					--- /home/jan/mysql/10.2/mysql-test/r/lock_sync.result	2016-06-30 15:27:02.839686282 +0300
			 | 
		
					+++ /home/jan/mysql/10.2/mysql-test/r/lock_sync.reject	2016-08-12 09:19:24.040144695 +0300
			 | 
		
					@@ -748,10 +748,20 @@
			 | 
		
					 # Wait until the above SELECT ... FOR UPDATE is blocked after
			 | 
		
					 # acquiring lock for the the first instance of 't1'.
			 | 
		
					 set debug_sync= 'now WAIT_FOR parked';
			 | 
		
					+Warnings:
			 | 
		
					+Warning	1639	debug sync point wait timed out
			 | 
		
					 # Send LOCK TABLE statement which will try to get TL_WRITE lock on 't1':
			 | 
		
					 lock table v1 write;;
			 | 
		
					 connection default;
			 | 
		
					 # Wait until this LOCK TABLES statement starts waiting for table lock.
			 | 
		
					+Timeout in wait_condition.inc for select count(*)= 1 from information_schema.processlist
			 | 
		
					+where state= 'Waiting for table level lock' and
			 | 
		
					+info='lock table v1 write'
			 | 
		
					+Id	User	Host	db	Command	Time	State	Info	Progress
			 | 
		
					+4	root	localhost	test	Query	0	init	show full processlist	0.000
			 | 
		
					+7	root	localhost	test	Sleep	231		NULL	0.000
			 | 
		
					+8	root	localhost	test	Sleep	31		NULL	0.000
			 | 
		
					+9	root	localhost	test	Sleep	331		NULL	0.000
			 | 
		
					 # Allow SELECT ... FOR UPDATE to resume.
			 | 
		
					 # Since it already has TL_WRITE_ALLOW_WRITE lock on the first instance
			 | 
		
					 # of 't1' it should be able to get lock on the second instance without
			 | 
		
					@@ -852,10 +862,7 @@
			 | 
		
					 # Reaping: OPTIMIZE TABLE t1
			 | 
		
					 Table	Op	Msg_type	Msg_text
			 | 
		
					 test.t1	optimize	note	Table does not support optimize, doing recreate + analyze instead
			 | 
		
					-test.t1	optimize	error	Lock wait timeout exceeded; try restarting transaction
			 | 
		
					-test.t1	optimize	status	Operation failed
			 | 
		
					-Warnings:
			 | 
		
					-Error	1205	Lock wait timeout exceeded; try restarting transaction
			 | 
		
					+test.t1	optimize	status	OK
			 | 
		
					 SET DEBUG_SYNC= 'now SIGNAL release_thrlock';
			 | 
		
					 disconnect con1;
			 | 
		
					 connection con2;
			 | 
		
Attachments
Issue Links
- is part of
 - 
                    
MDEV-10024 Fix test failures on InnoDB 5.7 in MariaDB 10.2
-         
 - Closed
 
 -