- 14 Jan, 2010 1 commit
-
-
Alfranio Correia authored
STMT mode aborts the SQL Thread if it receives changes in ROW mode and such changes are not processed.
-
- 05 Jan, 2010 1 commit
-
-
Alfranio Correia authored
In auto-commit mode, updating both trx and non-trx tables (i.e. issuing a mixed statement) causes the following sequence of events: 1 - "Flush trx changes" (MYSQL_BIN_LOG::write) - T1: 1.1 - mutex_lock (&LOCK_log) 1.2 - mutex_lock (&LOCK_prep_xids) 1.3 - increase prepared_xids 1.4 - mutex_unlock (&LOCK_prep_xids) 1.5 - mutex_unlock (&LOCK_log) 2 - "Flush non-trx changes" (MYSQL_BIN_LOG::write) - T1: 2.1 - mutex_lock (&LOCK_log) 2.2 - mutex_unlock (&LOCK_log) 3. "unlog" - T1 3.1 - mutex_lock (&LOCK_prep_xids) 3.2 - decrease prepared xids 3.3 - pthread_cond_signal(&COND_prep_xids); 3.4 - mutex_unlock (&LOCK_prep_xids) The "FLUSH logs" command produces the following sequence of events: 1 - "FLUSH logs" command (MYSQL_BIN_LOG::new_file_impl) - user thread: 1.1 - mutex_lock (&LOCK_log) 1.2 - mutex_lock (&LOCK_prep_xids) 1.3 - while (prepared_xids) pthread_cond_wait(..., &LOCK_prep_xids); 1.4 - mutex_unlock (&LOCK_prep_xids) 1.5 - mutex_unlock (&LOCK_log) A deadlock will arise if T1 flushes the trx changes and thus increases prepared_xids but before it is able to continue the execution and flush the non-trx changes, an user thread calls the "FLUSH logs" command and wait that the prepared_xids is decreased and gets to zero. However, T1 cannot proceed with the call to "Flush non-trx changes" because it will block in the mutex "LOCK_log" and by consequence cannot complete the execution and call the unlog to decrease the prepared_xids. To fix the problem, we ensure that the non-trx changes are always flushed before the trx changes. Note that if you call "Flush non-trx changes" and a concurrent "FLUSH logs" is issued, the "Flush non-trx changes" may block, but a deadlock will never happen because the prepared_xids will eventually get to zero. Bottom line, there will not be any transaction able to increase the prepared_xids because they will block in the mutex "LOCK_log" (MYSQL_BIN_LOG::write) and those that increased the prepared_xids will eventually commit and decrease the prepared_xids.
-
- 23 Dec, 2009 1 commit
-
- 21 Dec, 2009 1 commit
-
-
Alfranio Correia authored
-
- 18 Dec, 2009 1 commit
-
-
Luis Soares authored
The slave thread changed the format of the information it used to connect to the master after patch for BUG 13963. This resulted in old master getting confused, thence rejecting the slave connection attempt. In particular, patch for BUG 13963 removed the rpl_recovery_rank variable which was, at that time, packed together with the rest of the information which the slave would use to register itself on the master. Based on this data, the master would then assert that the number of bytes received in the connection command was consistent to what it was expecting. Therefore, given that a slave, patched with the aforementioned patch, would not pack the four bytes related to the rpl_recovery_rank variable, the old master would reject the connection attempt. It would assume that the data was inconsistent (fewer bytes than it was expecting) and return an error. We fix this by faking an rpl_recovery_rank variable when registering the slave on the master. In practice this reverts a small part of patch for BUG 13963, the one related to the slave connecting to the master.
-
- 14 Dec, 2009 2 commits
-
-
Sven Sandberg authored
Problem: The test was written before BUG#45827 was fixed. The test contained code that assumed the wrong behavior, pre-BUG#45827. Then, the fix for BUG#45827 was merged from 5.1-rep+2 to 5.1-rep+3. Since the test case assumed the wrong behavior, it failed. This should have been fixed by making the test assume the correct behavior, but was fixed by updating the result file to assert failure. Fix 1: fix the test to assume correct behavior (post-BUG#45827), update result file. Fix 2: make test fail with 'die' instead of 'exit' when wrong behavior is detected. Thus, the test cannot be silenced with a wrong result file in case the behavior will change again.
-
Alfranio Correia authored
-
- 03 Dec, 2009 1 commit
-
-
Support for flushing individual logs, so that the user can selectively flush a subset of the server logs. Flush of individual logs is done according to the following syntax: FLUSH <log_category> LOGS; The syntax is extended so that the user is able to flush a subset of logs: FLUSH [log_category LOGS,]; where log_category is one of: SLOW ERROR BINARY ENGINE GENERAL RELAY.
-
- 02 Dec, 2009 1 commit
-
-
Andrei Elkin authored
-
- 30 Nov, 2009 3 commits
-
-
Andrei Elkin authored
-
Andrei Elkin authored
-
Andrei Elkin authored
merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091104182209-iui387z35159aoyw
-
- 28 Nov, 2009 1 commit
-
-
Serge Kozlov authored
-
- 27 Nov, 2009 1 commit
-
-
Serge Kozlov authored
-
- 26 Nov, 2009 1 commit
-
-
Serge Kozlov authored
-
- 24 Nov, 2009 1 commit
-
-
Luis Soares authored
NOTE: backporting BUG#42150 into next-mr Includes latest Andrei's patch (see [2 Feb 18:40] Bugs System) and merge.test post-push fix (see [3 Feb 18:04] Bugs System) The reason of the bug appeared to be overreacting on absense of a binlog file although the file name had been presented in in the master binlog index file. By convention, there should have been only a warning printed and the rest of `reset master' logics completed. This did not happen on windows due to incorrect value of my_errno returned from nt_share_delete(). Fixed with correcting my_errno assignment in nt_share_delete() to be ENOENT in he event of no binlog file. Some minor refactoring has been made.
-
- 22 Nov, 2009 1 commit
-
-
Luis Soares authored
beyond unsigned long. BUG#44779: binlog.binlog_max_extension may be causing failure on next test in PB NOTE1: this is the backport to next-mr. NOTE2: already includes patch for BUG#44779. Binlog file extensions would turn into negative numbers once the variable used to hold the value reached maximum for signed long. Consequently, incrementing value to the next (negative) number would lead to .000000 extension, causing the server to fail. This patch addresses this issue by not allowing negative extensions and by returning an error on find_uniq_filename, when the limit is reached. Additionally, warnings are printed to the error log when the limit is approaching. FLUSH LOGS will also report warnings to the user, if the extension number has reached the limit. The limit has been set to 0x7FFFFFFF as the maximum.
-
- 20 Nov, 2009 1 commit
-
-
Andrei Elkin authored
The mentioned on the bug report set of bugs fixes have not be pushed to the main trees. Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1. Notes. 1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1 as http://lists.mysql.com/commits/46562 However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining people). 2. Bug@36929 crash in kill_zombie_dump_threads-> THD::awake() with replication tests is not backported because the base code of the patch is libevent and that was removed from the main trees due to its instability.
-
- 16 Nov, 2009 1 commit
-
-
Luis Soares authored
Post-push fix: Removed MTRv1 arguments according to the original patch. Although there is a version check, the patch was pushed to a 5.1 GA staging tree, while the version check considers version 5.2. This makes the deprecated parameters to be used, despite the fact that they are not valid anymore. Part of MTRv1 is currently used in RQG semisync test, and this was causing the test to fail on slave startup. It should be safe to uncomment when merging up to celosia.
-
- 15 Nov, 2009 1 commit
-
-
He Zhenxing authored
After fix of bug46322, logging to table is turned off, each test that need this should turn on it in it's opt file. Add suppression to unsafe statement warnings for binlog_unsafe.test.
-
- 13 Nov, 2009 5 commits
-
-
Luis Soares authored
Replication info files are not being flushed and synced when the command 'STOP SLAVE' is issued. This means that one cannot just rely on existing values on those files when the slave has been stopped. Having consistent, uncorrupted and up-to-date info files when stopping the slave would be most useful, for instance, for snapshotting purposes (a procedure that is often used for restoring slaves). This patch addresses this by instrumenting the terminate_slave_threads function so that it also flushes and syncs the *info files as well as the relay log whenever it gets called, ie, on 'STOP SLAVE'. Although this imposes a performance trade-off (specifically when stopping the slave), it should have no negative influence on overall replication performance (impact is only noticeable on 'STOP SLAVE').
-
Luis Soares authored
Post-push fix: Reverting change in Makefile.am which was causing windows not to build client/.
-
Luis Soares authored
CONFLICTS ========= Text conflict in sql/sql_yacc.yy 1 conflicts encountered.
-
Alfranio Correia authored
Create a set of test cases to see if some DDL statements implicitly commit a transaction on the NDB and are written directly to the binary log without going through either the Statement- or Transactional-Cache.
-
- 11 Nov, 2009 3 commits
-
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Luis Soares authored
Removed test case that was left without significance after backporting the deprecated constructs from 6.0 codebase.
-
- 10 Nov, 2009 1 commit
-
-
Andrei Elkin authored
merging 5.1 main -> 5.1-rep+2 -> 5.1-rep+3; binlog_unsafe , rpl_mysql_upgrade fail and are under treatment
-
- 06 Nov, 2009 1 commit
-
-
Andrei Elkin authored
-
- 04 Nov, 2009 6 commits
-
-
hery.ramilison@sun.com authored
-
Luis Soares authored
NOTE: Backport of: bzr log -r revid:sp1r-serg@sergbook.mysql.com-20070505200319-38337 ------------------------------------------------------------ revno: 2469.263.4 committer: serg@sergbook.mysql.com timestamp: Sat 2007-05-05 13:03:19 -0700 message: Removing deprecated features: --master-XXX command-line options log_bin_trust_routine_creators table_type BACKUP TABLE ... RESTORE TABLE ... SHOW PLUGIN LOAD TABLE ... FROM MASTER LOAD DATA FROM MASTER SHOW INNODB STATUS SHOW MUTEX STATUS SHOW TABLE TYPES ... TIMESTAMP(N) ... TYPE=engine RESET SLAVE don't reset connection parameters anymore LOAD DATA: check opt_secure_file_priv before access(filename) improved WARN_DEPRECATED macro
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 03 Nov, 2009 4 commits
-
-
Alfranio Correia authored
Non-transactional updates that take place inside a transaction present problems for logging because they are visible to other clients before the transaction is committed, and they are not rolled back even if the transaction is rolled back. It is not always possible to log correctly in statement format when both transactional and non-transactional tables are used in the same transaction. In the current patch, we ensure that such scenario is completely safe under the ROW and MIXED modes.
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Konstantin Osipov authored
Bug#41756 "Strange error messages about locks from InnoDB". In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. Unlocking of rows is done by the logic of the nested join loop, and is unaware of the possible caching that the access method may have. This could lead to double unlocking, when a row was unlocked first after reading into the cache, and then when taken from cache, as well as to unlocking of rows which were actually used (but taken from cache). Delegate part of the unlocking logic to the access method, and in JT_EQ_REF count how many times a record was actually used in the join. Unlock it only if it's usage count is 0. Implemented review comments.
-