| Bug #7947 | Wrong binlogging of CREATE [LIKE] | DROP TABLE if TEMPORARY and transaction | ||
|---|---|---|---|
| Submitted: | 16 Jan 2005 21:40 | Modified: | 21 Dec 2005 14:53 |
| Reporter: | Guilhem Bichot | ||
| Status: | Closed | ||
| Category: | Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 4.0 | OS: | Any (all) |
| Assigned to: | Bugs System | Target Version: | |
[25 Jan 2005 15:03]
Sergei Golubchik
There is the same problem with INSERT (and perhaps DELET/UPDATE): set autocommit=0; create temporary table t1 (a int) type=myisam; commit; insert t1 values (1); rollback; insert t0 select * from t1; (possible fix in mysql_insert() - remove log_delayed variable and use transactional_table instead)
[25 Jan 2005 18:22]
Sergei Golubchik
Same for item_user_lock_release():
SELECT GET_LOCK("lock1");
SET AUTOCOMMIT=0;
--- disconnect here
There will be no DO RELEASE_LOCK() in the binlog.
[30 Oct 2005 1:31]
Alexander Pachev
The original bug as well as the issue reported by Sergei with INSERT have already been fixed in the current code. The absence of DO RELEASE_LOCK() bug is still there. Still need to test DELETE/UPDATE.
[7 Nov 2005 23:09]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32059
[8 Nov 2005 4:51]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32072
[15 Nov 2005 21:38]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32288
[17 Nov 2005 5:17]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32348
[23 Nov 2005 0:32]
Alexander Pachev
Fixed in 4.1.16 and 5.0.17
[27 Nov 2005 3:28]
Alexander Pachev
Paul: The general nature of the problem is the failure to binlog events that still take place even when we ROLLBACK when ROLLBACK happens.
[21 Dec 2005 14:53]
Jon Stephens
Thank you for your bug report. This issue has already been fixed in the latest released version of that product, which you can download at http://www.mysql.com/downloads/ Additional info: Documented bugfix in 4.1.16 and 5.0.17 changelogs. Closed.
Description: Tested with 4.1: MASTER> begin; Query OK, 0 rows affected (0.05 sec) MASTER> create temporary table ti (a int) engine=innodb; Query OK, 0 rows affected (0.26 sec) MASTER> rollback; Query OK, 0 rows affected (0.00 sec) MASTER> insert into ti values(1); Query OK, 1 row affected (0.51 sec) MASTER> show binlog events; +---------------------+-----+------------+-----------+--------------+----------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | Orig_log_pos | Info | +---------------------+-----+------------+-----------+--------------+----------------------------------------------------------+ | gbichot2-bin.000001 | 4 | Start | 1 | 4 | Server ver: 4.1.10-valgrind-max-debug-log, Binlog ver: 3 | | gbichot2-bin.000001 | 79 | Query | 1 | 79 | use `test`; insert into ti values(1) | +---------------------+-----+------------+-----------+--------------+----------------------------------------------------------+ so slave will fail, saying that "ti" does not exist. How to repeat: see description Suggested fix: The guilty is this (mysql_create_table()): Query_log_event qinfo(thd, thd->query, thd->query_length, test(create_info->options & HA_LEX_CREATE_TMP_TABLE)); There is no reason for the test(...) thing: just putting 1 should solve the problem (verify that it does not automatically commit any started transactions, though). Same problem exists for CREATE TABLE LIKE, and DROP TABLE, at least (need to check everything to be sure).