Bug #16229 MySQL/InnoDB uses full explicit table locks in trigger processing

• Submitted: 5 Jan 2006 15:57
• Modified: 20 Jun 2010 1:08
• Reporter: Heikki Tuuri
• Status: Closed
• Category: MySQL Server: InnoDB storage engine
• Severity: S3 (Non-critical)
• Version: 5.0
• OS: Any (All)
• CPU Architecture: Any

[5 Jan 2006 15:57] Heikki Tuuri

Description:
Hi!

This was noted in the Forums:

http://forums.mysql.com/read.php?22,59979

A trigger requests an X-lock on the table, and ha_innobase::store_lock() does not weaken it, probably because MySQL has set:

thd->in_lock_tables == TRUE

and

thd->lex->sql_command != SQLCOM_CALL.

That can cause a lot of deadlocks and reduced concurrency.

Regards,

Heikki

How to repeat:
See above.

Suggested fix:
We should check what SQLCOM_... code corresponds to an explicit LOCK TABLES command by the user, and in all the other cases weaken lock_type not to take a full table lock.

[6 Jan 2006 15:22] Valeriy Kravchuk

Thank you for a problem report. Can you, please, provide a simple test case, because I had not found a trigger definition on that forum thread.

[7 Jan 2006 1:13] Heikki Tuuri

Valeriy,

I guess any trigger that modifies the table we are inserting into will serve as an example. InnoDB currently only weakens the locks in the SQLCOM_CALL case. But in trigger execution I guess it is SQLCOM_INSERT or similar.

Regards,

Heikki

[9 Jan 2006 10:52] Heikki Tuuri

Assigning this to Jan. Please check what SQLCOM_... code corresponds to an explicit LOCK TABLES command by the user. In other cases, weaken the lock like we do in the SQLCOM_CALL case (a stored procedure call).

[9 Jan 2006 11:12] Jan Lindström

Tested using 5.0.18 and query LOCK TABLES t1 READ. In this case thd->lex->sql_command == 
SQLCOM_LOCK_TABLES.

[9 Jan 2006 13:32] Jan Lindström

Verified using gdb (set a breakpoint to ha_innobase::external_lock) and using MySQL 5.0.18 with following test case:

CREATE TABLE t1 (id int NOT NULL, b int, PRIMARY KEY  (id)) ENGINE=InnoDB;
delimiter |
create trigger t1t after insert on t1 for each row begin update t1 set NEW.b = 5; end |
delimiter ;
insert into t1(id) values (111),(121),(131);

Here is gdb output:

Breakpoint 1, ha_innobase::external_lock (this=0x8cab360, thd=0x8c77788, lock_type=1) at ha_innodb.cc:6338

6338                    if (prebuilt->select_lock_type != LOCK_NONE) {
(gdb)
6340                            if (thd->in_lock_tables &&
(gdb)
6347                                                            NULL, 0);
(gdb) list 6346
6341                                thd->lex->sql_command != SQLCOM_CALL &&
6342                                thd->variables.innodb_table_locks &&
6343                                (thd->options & OPTION_NOT_AUTOCOMMIT)) {
6344
6345                                    ulint   error;
6346                                    error = row_lock_table_for_mysql(prebuilt,
6347                                                            NULL, 0);
6348
6349                                    if (error != DB_SUCCESS) {
6350                                            error = convert_error_code_to_mysql(
(gdb) p thd->in_lock_tables
$3 = true
(gdb) p thd->lex->sql_command
$4 = SQLCOM_INSERT

[31 Jan 2006 18:53] Alexander Ivanov

Fixed in 5.0.19.
Patch: http://lists.mysql.com/commits/1958.

[2 Feb 2006 17:53] Mike Hillyer

Documented in 5.0.19 changelog:

     <listitem>
        <para>
          InnoDB used full explicit table locks
          in trigger processing. (Bug #16229)
        </para>
      </listitem>

[24 May 2006 12:23] Dmitry Lenev

Bug #13893 was marked as duplicate of this bug.

[5 May 2010 15:27] Bugs System

Pushed into 5.1.47 (revid:[e-mail]-20100505145753-ivlt4hclbrjy8eye) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[6 May 2010 1:48] Paul DuBois

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.

[28 May 2010 6:13] Bugs System

Pushed into mysql-next-mr (revid:[e-mail]-20100524190136-egaq7e8zgkwb9aqi) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (pib:16)

[28 May 2010 6:41] Bugs System

Pushed into 6.0.14-alpha (revid:[e-mail]-20100524190941-nuudpx60if25wsvx) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[28 May 2010 7:08] Bugs System

Pushed into 5.5.5-m3 (revid:[e-mail]-20100524185725-c8k5q7v60i5nix3t) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[29 May 2010 23:13] Paul DuBois

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

[17 Jun 2010 12:18] Bugs System

Pushed into 5.1.47-ndb-7.0.16 (revid:[e-mail]-20100617114014-bva0dy24yyd67697) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[17 Jun 2010 13:05] Bugs System

Pushed into 5.1.47-ndb-6.2.19 (revid:[e-mail]-20100617115448-idrbic6gbki37h1c) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[17 Jun 2010 13:45] Bugs System

Pushed into 5.1.47-ndb-6.3.35 (revid:[e-mail]-20100617114611-61aqbb52j752y116) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)