- 28 Apr, 2010 2 commits
-
-
Sven Sandberg authored
Clarified error messages related to unsafe statements: - avoid the internal technical term "row injection" - use 'binary log' instead of 'binlog' - avoid the word 'unsafeness'
-
Stored routine DDL statements use statement-based replication regardless of the current binlog format. The problem here was that if a DDL statement failed during metadata lock acquisition or opening of mysql.proc, the binlog format would not be reset before returning. So the following DDL or DML statements are binlogged with a wrong binlog format, which causes the slave to stop. The problem can be resolved by grabbing an exclusive MDL lock firstly instead of clearing the current binlog format. So that the binlog format will not be affected when the lock grab returns directly with an error. The same way is taken to open a proc table for update.
-
- 27 Apr, 2010 5 commits
-
-
Luis Soares authored
parallel mode The failure has nothing to do with parallel, but rather on the order the tests are executed. In this case, the test binlog_tmp_table (lets call it test2) was not ensuring that the binary logs would be reset when it started. Later the test issues a mysqlbinlog .../master-bin.000002 | mysql ... If the test that was executed before this one (lets call it test1) had issued a flush logs, then the file in use in test1 (master-bin.000002) would not actually match the one that was expected. Eventually, this would cause the statements logged in test1 to be replayed, instead of the ones logged in the beginning of test2. We fix this by: 1. adding RESET MASTER to the beginning of binlog_tmp_table 2. setting dynamically the file to use in binlog_tmp_table Only #1 was needed, but the two make the tests cases more robust.
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Vladislav Vaintroub authored
The problem is that message resource (message.rc) is compiled as part of static library sql.lib rather than with executable mysqld.exe. resource files do not work in static libraries. The fix is to add message.rc to mysqld.exe source files list.
-
- 26 Apr, 2010 5 commits
-
-
Horst.Hunger authored
-
Horst.Hunger authored
-
Horst.Hunger authored
-
Alexander Nozdrin authored
-
Alfranio Correia authored
Statements with CONNECTION_ID were forced to be kept in the transactional cache and by consequence non-transactional changes that were supposed to be flushed ahead of the transaction were kept in the transactional cache. This happened because after BUG#51894 any statement whose thd's thread_specific_used was set was kept in the transactional cache. The idea was to keep changes on temporary tables in the transactional cache. However, the thread_specific_used was set not only for statements that accessed temporary tables but also when the CONNECTION_ID was used. To fix the problem, we created a new variable to keep track of updates to temporary tables.
-
- 22 Apr, 2010 1 commit
-
-
Alexander Nozdrin authored
The bug was a side effect of WL#5030 (fix header files) and WL#5161 (CMake). The problem was that CMake-generated config.h (and my_config.h as a copy of it) had a header guard. GNU autotools-generated [my_]config.h did not. During WL#5030 the order of header files was changed, so the following started to happen (using GNU autotools, in embedded server): - my_config.h included, defining HAVE_OPENSSL - my_global.h included, un-defining HAVE_OPENSSL - zlib.h included, including config.h, defining HAVE_OPENSSL again. The fix is to check HAVE_OPENSSL in conjuction with EMBEDDED_LIBRARY. More common fix would be to define a macros as HAVE_OPENSSL && !EMBEDDED_LIBRARY and use it instead of HAVE_OPENSSL.
-
- 21 Apr, 2010 6 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
The bug was a side effect of WL#5030 (fix header files) and WL#5161 (CMake). The problem was that CMake-generated config.h (and my_config.h as a copy of it) had a header guard. GNU autotools-generated [my_]config.h did not. During WL#5030 the order of header files was changed, so the following started to happen (using GNU autotools, in embedded server): - my_config.h included, defining HAVE_OPENSSL - my_global.h included, un-defining HAVE_OPENSSL - zlib.h included, including config.h, defining HAVE_OPENSSL again. The fix is to change the order of header file, moving zlib.h to the top of the header list. More proper fix would be to wrap unguarded auto-generated [my_]config.h by guarded non-generated header file.
-
Alfranio Correia authored
transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Post-merge fixes.
-
Jon Olav Hauglid authored
-
Jon Olav Hauglid authored
-
Mats Kindahl authored
-
- 20 Apr, 2010 3 commits
-
-
Mats Kindahl authored
Removing traces of mysql_priv.h from comments and other non-source files that were missed before.
-
Alfranio Correia authored
transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
-
Jon Olav Hauglid authored
-
- 19 Apr, 2010 5 commits
-
-
Alfranio Correia authored
-
Jon Olav Hauglid authored
Bug#30977 Concurrent statement using stored function and DROP FUNCTION breaks SBR Bug#48246 assert in close_thread_table
-
Vladislav Vaintroub authored
-
Alfranio Correia authored
-
Alexey Kopytov authored
-
- 18 Apr, 2010 1 commit
-
-
Joerg Bruehe authored
back into the development branches.
-
- 16 Apr, 2010 1 commit
-
-
Daniel Fischer authored
-
- 15 Apr, 2010 9 commits
-
-
Luis Soares authored
mysql-trunk-bugfixing (bug 52341).
-
Luis Soares authored
mysql-trunk-bugfixing.
-
Jon Olav Hauglid authored
This assertion could be triggered during execution of OPTIMIZE TABLE for InnoDB tables. As part of optimize for InnoDB tables, the table is recreated and then opened again. If the reopen failed for any reason, the assertion would be triggered. This could for example be caused by a concurrent DROP TABLE executed by a different connection. The reason for the assertion was that any failures during reopening were ignored. This patch fixes the problem by making sure that the result of reopening the table is checked and that any error messages are sent to the client. Test case added to innodb_mysql_sync.test.
-
Jon Olav Hauglid authored
This was a deadlock between CREATE/ALTER/DROP EVENT and a query accessing both the mysql.event table and I_S.GLOBAL_VARIABLES. The root of the problem was that the LOCK_event_metadata mutex was used to both protect the "event_scheduler" global system variable and the internal event data structures used by CREATE/ALTER/DROP EVENT. The deadlock would occur if CREATE/ALTER/DROP EVENT held LOCK_event_metadata while trying to open the mysql.event table, at the same time as the query had mysql.event open, trying to lock LOCK_event_metadata to access "event_scheduler". This bug was fixed in the scope of Bug#51160 by using only LOCK_global_system_variables to protect "event_scheduler". This makes it so that the query above won't lock LOCK_event_metadata, thereby preventing this deadlock from occuring. This patch contains no code changes. Test case added to lock_sync.test.
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
my_global.h first We may end up with a compilation failure on certain platforms because zlib.h is included before my_global.h. Fixed by moving zlib.h inclusion down after my_global.h.
-
Sergey Vojtovich authored
e.g.MYSQL_AUDIT_GENERAL_ERROR General audit API (MYSQL_AUDIT_GENERAL_CLASS) didn't expose event subclass to plugins. This patch exposes event subclass to plugins via struct mysql_event_general::event_subclass. This change is not compatible with existing general audit plugins. Audit interface major version has been incremented.
-
Alexander Nozdrin authored
-
Jon Olav Hauglid authored
even if myisam-recover is OFF The problem was that a corrupted MyISAM table was auto repaired even if the myisam_recover_options server variable (or the myisam_recover option) was set to OFF. The reason was that the auto_repair() function, which is supposed to say if auto repair is to be used, did not use the server variable setting correctly. This bug was a regression introduced by WL#4738. This patch fixes the problem by making sure auto_repair() returns FALSE if myisam_recover_options is set to OFF. Test case added to myisam.test.
-
- 14 Apr, 2010 2 commits
-
-
Alexander Nozdrin authored
The problem was that the code that works with stored routines was present in mysql_system_tables.sql. This is wrong because until upgrade is finished, stored routines may be (and were) not available. The fix is to move that code to the end of mysql_system_tables_fix.sql.
-
Jon Olav Hauglid authored
for write by another connection The problem was that if a table was locked in one connection by LOCK TABLES ... WRITE, REPAIR TABLE or OPTIMIZE TABLE, SHOW CREATE TABLE from another connection would be blocked. As SHOW CREATE TABLE only reads metadata about the table, such blocking is not needed. The problem was that when SHOW CREATE TABLE tried to get a metadata lock on the table in order to open it, it used the wrong type of metadata lock request. It used MDL_SHARED_READ which is used when the intent is to read both table metadata and table data. Instead it should have used MDL_SHARED_HIGH_PRIO which signifies an intent to only read metadata. This patch fixes the problem by making sure SHOW CREATE TABLE uses the MDL_SHARED_HIGH_PRIO metadata lock request type when trying to open the table. The patch also fixes a similar problem with the mysql_list_fields API call. Test case added to show_check.test.
-