Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10548

Some of the debug sync waits do not work with InnoDB 5.7 (branch bb-10.2-jan)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.2
    • Fix Version/s: N/A
    • Component/s: Tests
    • Labels:
      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

            Activity

              People

              Assignee:
              monty Michael Widenius
              Reporter:
              jplindst Jan Lindström
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.