mariadb

Commit Graph

Author	SHA1	Message	Date
Magnus Blåudd	f8e86f50e2	Bug#12384993 EXTRA/RPL_TEST/CHECK_TYPE.INC NEED SUPPORT FOR SPECIFIC ENGINE - add support for choosing the engine of test table(t1) with $engine_type - add primary key to the test table(t1) to support replication of BLOB/TEXT (also with ENGINE=ndb) - change the suppression since the warning printed to error log now says "Column 1"	15 years ago
Magnus Blåudd	767074e8b1	BUG#47741 rpl_ndb_extraCol fails in next-mr (mysql-5.1-rep+2) in RBR - fix the fix to properly detect when engine is NDB and also don't drop the table t9 if it hasn't been created	15 years ago
Bjorn Munch	b1dc6899c3	One more test suppression for rpl_extra_col_master tests	15 years ago
Bjorn Munch	9cd8fc9a61	Small followup fix after MTR warning cleanup	15 years ago
Bjorn Munch	c82e0399cb	mtr: cleaned up some superfluos global warning suppressions	15 years ago
Luis Soares	16e4677c5d	BUG#11766865: 60091: RBR + NO PK + UPDATE NULL VALUE --> SLAVE BREAK WITH ERROR HA_ERR_END_OF_ The slave was not able to find the correct row in the innodb table, because the row fetched from the innodb table would not match the before image. This happened because the (don't care) bytes in the NULLed fields would change once the row was stored in the storage engine (from zero to the default value). This would make bulk memory comparison (using memcmp) to fail. We fix this by taking a preventing measure and avoiding memcmp for tables that contain nullable fields. Therefore, we protect the slave search routine from engines that return arbitrary values for don't care bytes (in the nulled fields). Instead, the slave thread will only check null_bits and those fields that are not set to NULL when comparing the before image against the storage engine row.	15 years ago
Alfranio Correia	6d07a87a58	BUG#11877568 - RPL_SEMI_SYNC FAILS IN PB Currently, rpl_semi_sync is failing in PB due to the warning message: "Slave SQL: slave SQL thread is being stopped in the middle of " "applying of a group having updated a non-transaction table; " "waiting for the group completion ..." The problem started happening after the fix for BUG#11762407 what was automatically suppressing some warning messages. To fix the current issue, we suppress the aforementioned warning message and exploit the opportunity to make the sentence clearer.	15 years ago
Bjorn Munch	1f9d8cd862	Bug #11762407 54999: MTR GLOBAL SUPPRESSION HIDES SQL THREAD EXECUTION UNEXPECTED ERRORS Removed the global suppression, added lots of local ones to affected tests Re-commit, now kept "Slave SQL" at start of patterns.	15 years ago
Luis Soares	1c4ddcf0aa	BUG#11754075: BUG#45621: A FEW TEST FILES ARE DISABLED DUE TO WL#4284 Backporting the patch from BUG#11753489 into mysql-5.5 as it is already in mysql-trunk but not in mysql-5.5.	15 years ago
Alfranio Correia	66abb3d1bb	BUG#59338 Inconsistency in binlog for statements that don't change any rows STATEMENT SBR In SBR, if a statement does not fail, it is always written to the binary log, regardless if rows are changed or not. If there is a failure, a statement is only written to the binary log if a non-transactional (.e.g. MyIsam) engine is updated. INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE were not following the rule above and were not written to the binary log, if then engine was Innodb.	15 years ago
Luis Soares	69465fcf9d	BUG#59444 Added comments to rpl_show_relaylog_events as requested by reviewer.	15 years ago
Luis Soares	8734d5db1e	BUG#59444 Refactoring effort on test case rpl_show_relaylog_events requested by reviewers.	15 years ago
Luis Soares	ac8e0ec1b1	BUG#59444: rpl_row_show_relaylog_events fails on daily-5.5 test runs The test started failing on the same day patch for BUG 49978 was pushed. BUG 49978 changed part of the replication testing infrastructure in mysql-test-run. This caused the test to fail sporadically with result differences on relay log file names. When the test fails the relay-log filenames are shifted by one, eg: -show relaylog events in 'slave-relay-bin.000002' from <binlog_start>; +show relaylog events in 'slave-relay-bin.000003' from <binlog_start>; The problem was caused by a bad cleanup when using the include files: - include/setup_fake_relay_log.inc - include/cleanup_fake_relay_log.inc Which would leave a spurious relay-log file around (not listed in slave-relay-bin.index), causing the server to shift the name of the relay logs by one, even if cleaning up with RESET SLAVE. We fix this by removing the relay-log file when it is not needed anymore, ie at setup time and after recreating the fake relay-log index. Additionally, to make the affected test more resilient, we deployed a call to rpl_reset.inc (which resets both master and slave, including log files) before actually running the test case. Finally, appart from the reported bug, we also fix: (a) an unrelated issue with the failing test itself - in some cases, the test was not setting the log file name to use when it should; (b) one typo.	15 years ago
	16ca2deb90	Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event.	15 years ago
Sven Sandberg	09c80e12c5	BUG#49978: Replication tests don't clean up replication state at the end Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql\|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start\|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.	15 years ago
Bjorn Munch	11746c8000	some more if stmt simplifications	15 years ago
Bjorn Munch	7c6151ff18	Bug #58515 Tests: use use exec echo, not write_file to write mysqld.1.expect Fixed as suggested in the .inc file and two tests Could not reproduce problem, but tested tests on Windows	15 years ago
Bjorn Munch	20851e4012	Bug #58412 mysqltest: allow quoting of strings in let and in if comparison Stripping quotes in let was a bad idea, will not fix Added code to strip quotes from rhs in comparisons	15 years ago
Sven Sandberg	a3028ec49a	Made tests clean up after themselves.	15 years ago
Bjorn Munch	0f551def8f	Tests: many if/while expresissons simplified after 57276	15 years ago
Alfranio Correia	bf2c66d4a7	BUG#57275 binlog_cache_size affects trx- and stmt-cache and gets twice the expected memory After the WL#2687, the binlog_cache_size and max_binlog_cache_size affect both the stmt-cache and the trx-cache. This means that the resource used is twice the amount expected/defined by the user. The binlog_cache_use is incremented when the stmt-cache or the trx-cache is used and binlog_cache_disk_use is incremented when the disk space from the stmt-cache or the trx-cache is used. This behavior does not allow to distinguish which cache may be harming performance due to the extra disk accesses and needs to have its in-memory cache increased. To fix the problem, we introduced two new options and status variables related to the stmt-cache: Options: . binlog_stmt_cache_size . max_binlog_stmt_cache_size Status Variables: . binlog_stmt_cache_use . binlog_stmt_cache_disk_use So there are . binlog_cache_size that defines the size of the transactional cache for updates to transactional engines for the binary log. . binlog_stmt_cache_size that defines the size of the statement cache for updates to non-transactional engines for the binary log. . max_binlog_cache_size that sets the total size of the transactional cache. . max_binlog_stmt_cache_size that sets the total size of the statement cache. . binlog_cache_use that identifies the number of transactions that used the temporary transactional binary log cache. . binlog_cache_disk_use that identifies the number of transactions that used the temporary transactional binary log cache but that exceeded the value of binlog_cache_size. . binlog_stmt_cache_use that identifies the number of statements that used the temporary non-transactional binary log cache. . binlog_stmt_cache_disk_use that identifies the number of statements that used the temporary non-transactional binary log cache but that exceeded the value of binlog_stmt_cache_size.	15 years ago
Bjorn Munch	bad7fa7c90	Follow-up to Bug #55582 which allows checking strings in if Simplified cases where a select was used to compare variable against ''	15 years ago
Bjorn Munch	9ec05efe34	Follow-up to Bug #55582 which allows chaecking strings in if Simplified cases where a select was used to compare variable against ''	15 years ago
	131e3e38fd	Bug#56118 STOP SLAVE does not wait till trx with CREATE TMP TABLE ends, replication aborts When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the transaction and stop immidiately if there is only transactional table updated, even through 'CREATE\|DROP TEMPOARY TABLE' statement are in it. But These statements can never be rolled back. Because the temporary tables to the user session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread with an error that the table already exists or doesn't exist, when it restarts and executes the whole transaction again. After this patch, SQL thread always waits till the transaction ends and then stops, if 'CREATE\|DROP TEMPOARY TABLE' statement are in it.	15 years ago
Davi Arnaut	7d64c36486	Bug#56096: STOP SLAVE hangs if executed in parallel with user sleep The root of the problem is that to interrupt a slave SQL thread wait, the STOP SLAVE implementation uses thd->awake(THD::NOT_KILLED). This appears as a spurious wakeup (e.g. from a sleep on a condition variable) to the code that the slave SQL thread is executing at the time of the STOP. If the code is not written to be spurious-wakeup safe, unexpected behavior can occur. For the reported case, this problem led to an infinite loop around the interruptible_wait() function in item_func.cc (SLEEP() function implementation). The loop was not being properly restarted and, consequently, would not come to an end. Since the SLEEP function sleeps on a timed event in order to be killable and to perform periodic checks until the requested time has elapsed, the spurious wake up was causing the requested sleep time to be reset every two seconds. The solution is to calculate the requested absolute time only once and to ensure that the thread only sleeps until this time is elapsed. In case of a spurious wake up, the sleep is restarted using the previously calculated absolute time. This restores the behavior present in previous releases. If a slave thread is executing a SLEEP function, a STOP SLAVE statement will wait until the time requested in the sleep function has elapsed.	15 years ago
Dmitry Lenev	8007ef52f1	Fix for bug #57422 "rpl_row_sp003 sporadically fails under heavy load". rpl_row_sp003.test has sporadically failed when run on machine under heavy load or on slow hardware. This patch fixes races in the test which were causing these failures and also removes unnecessary 100 second wait from it.	15 years ago
	0688c086a0	Bug #54579 Wrong unsafe warning for INSERT DELAYED in SBR The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for INSERT DELAYED when inserting multi values in one statement. It's safe. But it causes an unsafe warning in SBR. Make INSERT DELAYED safe by logging it as INSERT without DELAYED.	15 years ago
Alfranio Correia	c6d4915f3c	BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with temp table This patch introduces two key changes in the replication's behavior. Firstly, it reverts part of BUG#51894 which puts any update to temporary tables into the trx-cache. Now, updates to temporary tables are handled according to the type of their engines as a regular table. Secondly, an unsafe mixed statement, (i.e. a statement that access transactional table as well non-transactional or temporary table, and writes to any of them), are written into the trx-cache in order to minimize errors in the execution when the statement logging format is in use. Such changes has a direct impact on which statements are classified as unsafe statements and thus part of BUG#53259 is reverted.	15 years ago
	b766a51f41	WL#5370 Keep forward-compatibility when changing 'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed in this patch too. This is the 5.1 part. It implements: - if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS and INSERT ... SELECT - Insert nothing and binlog nothing on master if the existing object is a view. It only generates a warning that table already exists.	15 years ago
Alfranio Correia	bd3aa7eb78	BUG#50312 Warnings for unsafe sub-statement not returned to client After BUG#36649, warnings for sub-statements are cleared when a new sub-statement is started. This is problematic since it suppresses warnings for unsafe statements in some cases. It is important that we always give a warning to the client, because the user needs to know when there is a risk that the slave goes out of sync. We fixed the problem by generating warning messages for unsafe statements while returning from a stored procedure, function, trigger or while executing a top level statement. We also started checking unsafeness when both performance and log tables are used. This is necessary after the performance schema which does a distinction between performance and log tables.	16 years ago
Dmitry Lenev	a6c00c276e	Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and FLUSH TABLES <list> WITH READ LOCK are incompatible" to be pushed as separate patch. Replaced thread state name "Waiting for table", which was used by threads waiting for a metadata lock or table flush, with a set of names which better reflect types of resources being waited for. Also replaced "Table lock" thread state name, which was used by threads waiting on thr_lock.c table level lock, with more elaborate "Waiting for table level lock", to make it more consistent with other thread state names. Updated test cases and their results according to these changes. Fixed sys_vars.query_cache_wlock_invalidate_func test to not to wait for timeout of wait_condition.inc script.	16 years ago
	aa1572f46d	Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile With statement- or mixed-mode logging, "LOAD DATA INFILE" queries are written to the binlog using special types of log events. When mysqlbinlog reads such events, it re-creates the file in a temporary directory with a generated filename and outputs a "LOAD DATA INFILE" query where the filename is replaced by the generated file. The temporary file is not deleted by mysqlbinlog after termination. To fix the problem, in mixed mode we go to row-based. In SBR, we document it to remind user the tmpfile is left in a temporary directory.	16 years ago
Andrei Elkin	48d1c50ac1	bug#54935 applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug	16 years ago
Alfranio Correia	34664b6abb	WL#5344	16 years ago
Alfranio Correia	e662b51eef	BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables BUG#54872 MBR: replication failure caused by using tmp table inside transaction Changed criteria to classify a statement as unsafe in order to reduce the number of spurious warnings. So a statement is classified as unsafe when there is on-going transaction at any point of the execution if: 1. The mixed statement is about to update a transactional table and a non-transactional table. 2. The mixed statement is about to update a temporary transactional table and a non-transactional table. 3. The mixed statement is about to update a transactional table and read from a non-transactional table. 4. The mixed statement is about to update a temporary transactional table and read from a non-transactional table. 5. The mixed statement is about to update a non-transactional table and read from a transactional table when the isolation level is lower than repeatable read. After updating a transactional table if: 6. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 7. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 8. The mixed statement is about to update a non-transactionala table and read from a temporary non-transactional table. 9. The mixed statement is about to update a temporary non-transactional table and update a non-transactional table. 10. The mixed statement is about to update a temporary non-transactional table and read from a non-transactional table. 11. A statement is about to update a non-transactional table and the option variables.binlog_direct_non_trans_update is OFF. The reason for this is that locks acquired may not protected a concurrent transaction of interfering in the current execution and by consequence in the result. So the patch reduced the number of spurious unsafe warnings. Besides we fixed a regression caused by BUG#51894, which makes temporary tables to go into the trx-cache if there is an on-going transaction. In MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have updates to temporary non-transactional tables that must be written to the binary log while rolling back the transaction. So we fix this problem by writing the content of the trx-cache to the binary log while rolling back a transaction if a non-transactional temporary table was updated and the binary logging format is MIXED.	16 years ago
	a34ea0e4ba	Postfix for bug49741	16 years ago
	5873b972d9	Postfix for BUG#49741 Add code to waiting for a set of errors. Add code to waiting for an error instead of waiting for io thread to stop, as after 'START SLAVE', the status of io thread is still not running. But it doesn't mean slave io thread encounters an error.	16 years ago
	69c9dbabe6	Postfix BUG#49741	16 years ago
	cc05440836	Bug #49741 test files contain explicit references to bin/relay-log positions Some of the test cases reference to binlog position and these position numbers are written into result explicitly. It is difficult to maintain if log event format changes. There are a couple of cases explicit position number appears, we handle them in different ways A. 'CHANGE MASTER ...' with MASTER_LOG_POS or/and RELAY_LOG_POS options Use --replace_result to mask them. B. 'SHOW BINLOG EVENT ...' Replaced by show_binlog_events.inc or wait_for_binlog_event.inc. show_binlog_events.inc file's function is enhanced by given $binlog_file and $binlog_limit. C. 'SHOW SLAVE STATUS', 'show_slave_status.inc' and 'show_slave_status2.inc' For the test cases just care a few items in the result of 'SHOW SLAVE STATUS', only the items related to each test case are showed. 'show_slave_status.inc' is rebuild, only the given items in $status_items will be showed. 'check_slave_is_running.inc' and 'check_slave_no_error.inc' and 'check_slave_param.inc' are auxiliary files helping to show running status and error information easily.	16 years ago
Andrei Elkin	b530d5660e	reverting fixes for Bug@50316 in mysql-trunk	16 years ago
Andrei Elkin	9e3c410ae7	bug#50316 Add Master_info_file to SHOW SLAVE STATUS pushing to next-mr-bugfixing from working branch	16 years ago
Sven Sandberg	a651824329	BUG#50670: Slave stops with error code 1644 Clarified error messages related to unsafe statements: - avoid the internal technical term "row injection" - use 'binary log' instead of 'binlog' - avoid the word 'unsafeness'	16 years ago
Luis Soares	ddb5d63346	BUG#52868: Wrong handling of NULL value during update, replication out of sync In RBR, sometimes the table->s->last_null_bit_pos can be zero. This has impact at the slave when it compares records fetched from the storage engine against records in the binary log event. If last_null_bit_pos is zero the slave, while comparing in log_event.cc:record_compare function, would set all bits in the last null_byte to 1 (assumed all 8 were unused) . Thence it would loose the ability to distinguish records that were similar in contents except for the fact that some field was null in one record, but not in the other. Ultimately this would cause wrong matches, and in the specific case depicted in the bug report the same record would be updated twice, resulting in a lost update. Additionally, in the record_compare function the slave was setting the X bit unconditionally. There are cases that the X bit does not exist in the record header. This could also lead to wrong matches between records. We fix both by conditionally resetting the bits: (i) unused null_bits are set if last_null_bit_pos > 0; (ii) X bit is set if HA_OPTION_PACK_RECORD is in use.	16 years ago
Alfranio Correia	9ba731c299	BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a 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.	16 years ago
Alfranio Correia	7827688f23	BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates BUG#46364 introduced the flag binlog_direct_non_transactional_updates which would make N-changes to be written to the binary log upon committing the statement when "ON". On the other hand, when "OFF" the option was supposed to mimic the behavior in 5.1. However, the implementation was not mimicking the behavior correctly and the following bugs popped up: Case #1: N-changes executed within a transaction would go into the S-cache. When later in the same transaction a T-change occurs, N-changes following it were written to the T-cache instead of the S-cache. In some cases, this raises problems. For example, a Table_map_log_event being written initially into the S-cache, together with the initial N-changes, would be absent from the T-cache. This would log N-changes orphaned from a Table_map_log_event (thence discarded at the slave). (MIXED and ROW) Case #2: When rolling back a transaction, the N-changes that might be in the T-cache were disregarded and truncated along with the T-changes. (MIXED and ROW) Case #3: When a MIXED statement (TN) is ahead of any other T-changes in the transaction and it fails, it is kept in the T-cache until the transaction ends. This is not the case in 5.1 or Betony (5.5.2). In these, the failed TN statement would be written to the binlog at the same instant it had failed and not deferred until transaction end. (SBR) To fix these problems, we have decided to do what follows: For Case #1 and #2, we circumvent them: 1. by not letting binlog_direct_non_transactional_updates affect MIXED and RBR. These modes will keep the behavior provided by WL#2687. Although this will make Celosia to behave differently from 5.1, an execution will be always safe under such modes in the sense that slaves will never go out sync. In 5.1, using either MIXED or ROW while mixing N-statements and T-statements was not safe. For Case #3, we don't actually fix it. We: 1. keep it and make all MIXED statements whether they end up failing or not or whether they are up front in the transaction or after some transactional change to always be stored in the T-cache. This means that it is written to the binary log on transaction commit/rollback only. 2. We make the warning message even more specific about the MIXED statement and SBR.	16 years ago
Andrei Elkin	30df18909c	Bug #51648 DBUG_SYNC_POINT is not defined on all platforms and mtr cant pre-check that DBUG_SYNC_POINT has at least one strong limitation that it's not defined on all platforms. It has issues cooperating with @@debug. All in all its functionality is superseded by DEBUG_SYNC facility and there is no reason to maintain the old less flexible one. Fixed with adding debug_sync_set_action() function as a facility to set up a sync-action in the server sources code and re-writing existing simulations (found 3) to use it. Couple of tests have been reworked as well. The patch offers a pattern for setting sync-points in replication threads where the standard DEBUG_SYNC does not suffice to reach goals.	16 years ago
Luis Soares	635a83cc03	BUG#50451: rpl_loaddata_concurrent fails sporadically When using MyIsam tables and processing concurrent DML statements, the server may be sending back an OK to the client before actually finishing the transaction commit procedure. This has been reported before in BUG@37521 and BUG@29334. This particular test case gets affected, because it performs the following sequence: connect (conn2, ...) connection conn2; LOAD DATA CONCURRENT ... disconnect (conn2, ...) connection master; sync_slave_with_master diff_tables At this point diff_tables may report difference in the table content (the master seems to be missing the conn2 rows). To workaround this MyISAM concurrent DML statements issue and make this test case deterministic, we wait on conn2 until the rows inserted show up in the table. After this the test case proceeds as normally would before this patch.	16 years ago
Alexander Nozdrin	f392eddabc	Revert a patch for Bug#48231, which introduced valgrind warnings. Original revision: ------------------------------------------------------------ revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk committer: <Li-Bing.Song@sun.com> branch nick: mysql-5.1-bugteam timestamp: Sat 2010-01-30 20:49:25 +0800 message: Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; REVOKE/GRANT; ALTER EVENT. The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENT but, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, All above statements are rewritten when they are binlogged. The CURRENT_USER() is expanded to the real user's name and host. ------------------------------------------------------------	16 years ago
Alexander Nozdrin	33e5e125f5	Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing. Conflicts: - mysql-test/r/mysqld--help-win.result - sql/sys_vars.cc Original revsion (in next-mr-bugfixing): ------------------------------------------------------------ revno: 2971 [merge] revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1 committer: Alfranio Correia <alfranio.correia@sun.com> branch nick: mysql-next-mr-bugfixing timestamp: Thu 2010-01-21 21:05:27 +0000 message: BUG#46364 MyISAM transbuffer problems (NTM problem) It is well-known that due to concurrency issues, a slave can become inconsistent when a transaction contains updates to both transaction and non-transactional tables. In a nutshell, the current code-base tries to preserve causality among the statements by writing non-transactional statements to the txn-cache which is flushed upon commit. However, modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections but may not immediately get into the binary log and therefore consistency may be broken. In general, it is impossible to automatically detect causality/dependency among statements by just analyzing the statements sent to the server. This happen because dependency may be hidden in the application code and it is necessary to know a priori all the statements processed in the context of a transaction such as in a procedure. Moreover, even for the few cases that we could automatically address in the server, the computation effort required could make the approach infeasible. So, in this patch we introduce the option - "--binlog-direct-non-transactional-updates" that can be used to bypass the current behavior in order to write directly to binary log statements that change non-transactional tables. Besides, it is used to enable the WL#2687 which is disabled by default. ------------------------------------------------------------ revno: 2970.1.1 revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0 parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0 committer: Alfranio Correia <alfranio.correia@sun.com> branch nick: mysql-next-mr-bugfixing timestamp: Thu 2010-01-21 13:10:34 +0000 message: BUG#46364 MyISAM transbuffer problems (NTM problem) It is well-known that due to concurrency issues, a slave can become inconsistent when a transaction contains updates to both transaction and non-transactional tables. In a nutshell, the current code-base tries to preserve causality among the statements by writing non-transactional statements to the txn-cache which is flushed upon commit. However, modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections but may not immediately get into the binary log and therefore consistency may be broken. In general, it is impossible to automatically detect causality/dependency among statements by just analyzing the statements sent to the server. This happen because dependency may be hidden in the application code and it is necessary to know a priori all the statements processed in the context of a transaction such as in a procedure. Moreover, even for the few cases that we could automatically address in the server, the computation effort required could make the approach infeasible. So, in this patch we introduce the option - "--binlog-direct-non-transactional-updates" that can be used to bypass the current behavior in order to write directly to binary log statements that change non-transactional tables. Besides, it is used to enable the WL#2687 which is disabled by default.	16 years ago
	788c28aceb	Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; REVOKE/GRANT; ALTER EVENT. The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENT but, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, All above statements are rewritten when they are binlogged. The CURRENT_USER() is expanded to the real user's name and host.	16 years ago

1 2 3 4 5 ...

443 Commits (68e6a24d1cb4c1c281f7f753b2e65ed1434c26b3)