| Bug #18350 | Use consistent read in CREATE ... SELECT... if innodb_locks_unsafe_for_binlog | ||
|---|---|---|---|
| Submitted: | 20 Mar 2006 10:43 | Modified: | 19 Jun 2010 18:02 |
| Reporter: | Heikki Tuuri | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
| Version: | 5.0, 5.1 | OS: | Any (All) |
| Assigned to: | CPU Architecture: | Any | |
[21 Mar 2006 9:57]
Jan Lindström
Applied to 5.0 and 5.1 in InnoDB internal svn.
[24 Apr 2006 11:42]
Alexander Ivanov
Fixed in 5.0.21 and 5.1.10-beta.
[27 Apr 2006 15:22]
Paul DuBois
Noted in 5.0.21, 5.1.10 changelogs. <literal>InnoDB</literal> did not use a consistent read for <literal>CREATE ... SELECT</literal> when <literal>innodb_locks_unsafe_for_binlog</literal> was set. (Bug #18350)
[5 May 2010 15:15]
Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 1:58]
Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[28 May 2010 6:02]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:31]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 6:58]
Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 May 2010 22:47]
Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[17 Jun 2010 12:06]
Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 12:51]
Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:33]
Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Description: In 5.0, InnoDB sets prebuilt->select_lock_type=LOCK_S in CREATE ... SELECT... even if innodb_locks_unsafe_for_binlog is in my.cnf. It should use a consistent read. Workaround: create the table first and use INSERT ... SELECT ... How to repeat: See above. Suggested fix: In ha_innodb.cc, in ::store_lock(): " if (srv_locks_unsafe_for_binlog && prebuilt->trx->isolation_level != TRX_ISO_SERIALIZABLE && (lock_type == TL_READ || lock_type == TL_READ_NO_INSERT) && (thd->lex->sql_command == SQLCOM_INSERT_SELECT || thd->lex->sql_command == SQLCOM_UPDATE)) { /* In case we have innobase_locks_unsafe_for_binlog option set and isolation level of the transaction is not set to serializable and MySQL is doing INSERT INTO...SELECT or UPDATE ... = (SELECT ...) without FOR UPDATE or IN SHARE MODE in select, then we use consistent read for select. */ prebuilt->select_lock_type = LOCK_NONE; prebuilt->stored_select_lock_type = LOCK_NONE; " replace: (thd->lex->sql_command == SQLCOM_INSERT_SELECT || thd->lex->sql_command == SQLCOM_UPDATE)) { by: (thd->lex->sql_command == SQLCOM_INSERT_SELECT || thd->lex->sql_command == SQLCOM_UPDATE || thd->lex->sql_command == SQLCOM_CREATE_TABLE)) {