Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Test main.innodb_mysql_lock is unstable

Description

Seen on PS 5.5 trunk, ASan, https://jenkins.percona.com/job/percona-server-5.5-asan-param/159/BUILD_TYPE=debug-asan,Host=ubuntu-xenial-64bit/consoleText:

main.innodb_mysql_lock w3 [ fail ] Test ended at 2018-01-19 08:22:17 CURRENT_TEST: main.innodb_mysql_lock mysqltest: At line 51: query 'INSERT INTO t1 VALUES (2)' succeeded - should have failed with errno 1213... The result from queries just before the failure was: # # Bug #22876 Four-way deadlock # DROP TABLE IF EXISTS t1; # Connection 1 set @@autocommit=0; CREATE TABLE t1(s1 INT UNIQUE) ENGINE=innodb; INSERT INTO t1 VALUES (1); # Connection 2 set @@autocommit=0; INSERT INTO t1 VALUES (2); INSERT INTO t1 VALUES (1); # Connection 3 set @@autocommit=0; DROP TABLE t1; # Connection 1 # Connection 1 is now holding the lock. # Issuing insert from connection 1 while connection 2&3 # is waiting for the lock should give a deadlock error. safe_process[7499]: Child process: 7500, exit: 1

It also matches https://jira.mariadb.org/browse/MDEV-7861

Environment

None

Smart Checklist

Activity

Show:

Laurynas Biveinis January 23, 2018 at 10:41 AM

The fix would be to backport

commit 0454f5aba958117a777bab005ed36815a073d3c7

Author: Dmitry Shulga <Dmitry.Shulga@oracle.com>

Date:   Mon Mar 19 13:38:46 2012 +0600

 

    Fixed bug#13625834 - main.innodb_mysql_lock test fails on debian5.0-x86_64

                         sporadically.

    

    The reason for this bug is that there was a race condition in checking for

    'update' state in wait_condition loop and acquiring real transaction lock

    during execution of statement 'INSERT'. Such race condition arised since

    there was a time window between the step when server sets a transaction state

    in 'update' value and when the real lock for transation is acquired. Such

    race condition could result in successful execution of the following statement

    'INSERT INTO t1 VALUES (2)' that else should failed with error

    ER_LOCK_DEADLOCK.

    

    To eliminate this race condition we replaced the conditon of waiting for

    lock by polling the table information_schema.innodb_trx until transaction will

    be locked.

 

Done

Details

Assignee

Reporter

Labels

Fix versions

Affects versions

Priority

Smart Checklist

Created January 23, 2018 at 10:32 AM
Updated February 13, 2018 at 8:42 PM
Resolved January 25, 2018 at 5:08 AM