An error occurred fetching the project authors.
- 13 Jan, 2010 1 commit
-
-
Sven Sandberg authored
Problem: When RAND() is binlogged in statement mode, the seed is binlogged too, so the replication slave generates the same sequence of random numbers. This makes replication work in many cases, but not in all cases: the order of rows is not guaranteed for, e.g., UPDATE or INSERT...SELECT statements, so the row data will be different if master and slave retrieve the rows in different orders. Fix: Mark RAND() as unsafe. It will generate a warning if binlog_format=STATEMENT and switch to row-logging if binlog_format=ROW.
-
- 18 Nov, 2009 1 commit
-
-
Sven Sandberg authored
Problem: Some system functions that could return different values on master and slave were not marked unsafe. In particular: GET_LOCK IS_FREE_LOCK IS_USED_LOCK MASTER_POS_WAIT RELEASE_LOCK SLEEP SYSDATE VERSION Fix: Mark these functions unsafe.
-
- 02 Feb, 2009 1 commit
-
-
Serge Kozlov authored
The patch adds restart of mysql server and replacing of binlog file when mysql server is stopped.
-
- 01 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 27 Jan, 2009 1 commit
-
-
Luis Soares authored
The test fails with timeout when applying diff on two tables. In this test case, there can be a situation when the slave is not yet synced with the master, thence the changes may not be on the slave at diff time. This patch addresses this issue by synchronizing master and slave before the diff takes place.
-
- 05 Dec, 2008 1 commit
-
-
Mats Kindahl authored
Uncommited changes are replicated and stay on slave after rollback on master Making test slightly more generic and robust.
-
- 03 Dec, 2008 1 commit
-
-
Mats Kindahl authored
after rollback on master When starting a transaction with a statement containing changes to both transactional tables and non-transactional tables, the statement is considered as non-transactional and is therefore written directly to the binary log. This behaviour was present in 5.0, and has propagated to 5.1. If a trigger containing a change of a non-transactional table is added to a transactional table, any changes to the transactional table is "tainted" as non-transactional. This patch solves the problem by removing the existing "hack" that allows non-transactional statements appearing first in a transaction to be written directly to the binary log. Instead, anything inside a transaction is treaded as part of the transaction and not written to the binary log until the transaction is committed.
-
- 12 Dec, 2007 1 commit
-
-
msvensson@pilot.mysql.com authored
- dynamic configuration support - safe process - cleanups - create new suite for fedarated
-
- 08 Nov, 2007 1 commit
-
-
mats@kindahl-laptop.dnsalias.net authored
-
- 27 Jun, 2007 1 commit
-
-
msvensson@pilot.(none) authored
- Update mysql-test-run.pl to collect tests from several suites - Group test into suites - Add suite.opt file
-
- 13 Nov, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
This change set implements the DROP TRIGGER IF EXISTS functionality. This fix is considered a bug and not a feature, because without it, there is no known method to write a database creation script that can create a trigger without failing, when executed on a database that may or may not contain already a trigger of the same name. Implementing this functionality closes an orthogonality gap between triggers and stored procedures / stored functions (which do support the DROP IF EXISTS syntax). In sql_trigger.cc, in mysql_create_or_drop_trigger, the code has been reordered to: - perform the tests that do not depend on the file system (access()), - get the locks (wait_if_global_read_lock, LOCK_open) - call access() - perform the operation - write to the binlog - unlock (LOCK_open, start_waiting_global_read_lock) This is to ensure that all the code that depends on the presence of the trigger file is executed in the same critical section, and prevents race conditions similar to the case fixed by Bug 14262 : - thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure - thread 2 executes CREATE TRIGGER - thread 2 logs CREATE TRIGGER - thread 1 logs DROP TRIGGER IF EXISTS The patch itself is based on code contributed by the MySQL community, under the terms of the Contributor License Agreement (See Bug 18161).
-
- 24 Oct, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 30 Aug, 2006 1 commit
-
-
aelkin/elkin@andrepl.dsl.inet.fi authored
The following is an excerption from the WL. 1. Change so that MIXED is default format 1.1 to change the default for command line --binlog-format 1.2 to alter global_system_variables.binlog_format calculation basing on command line --binlog-format parameter and its default. 2. Change test suite so that more testing is done by MIXED format. 2.1 to check if there are test cases requiring --binlog-foramt=statement via `source include/have_binlog_format_statement.inc' and affected by altering the latter to be "mixed". 2.2 to check the content of such vulnerable cases to find if extending to the mixed does not modify results. In that case simply substitute source arguments as explained. 2.3 if a test in mixed mode deals with features triggering row-binlogging then if necessary we can switch explicitly to statement mode or create another test to run with non-recommended STATEMENT mode Particullarily, extracting INSERT DELAYED binlogging subtest for statement mode is performed, and the snippet is moved into a separate test file. Note that since now all three modes verify this use case through 3 different tests. No changes in item 3 of HLD appeared to be needed.
-
- 27 Jul, 2006 1 commit
-
-
anozdrin/alik@booka. authored
can be not replicable. Now CREATE statements for writing in the binlog are created as follows: - the beginning of the statement is re-created; - the rest of the statement is copied from the original query. The problem appears when there is a version-specific comment (produced by mysqldump), started in the re-created part of the statement and closed in the copied part -- there is closing comment-parenthesis, but there is no opening one. The proper fix could be to re-create original statement, but we can not implement it in 5.0. So, for 5.0 the fix is just to cut closing comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE statement (so we are able to reuse existing code).
-
- 07 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
only its own tables to prevent getting tables from others.
-
- 01 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
The idea of the fix is to extend support of non-SUID triggers for backward compatibility. Formerly non-SUID triggers were appeared when "new" server is being started against "old" database. Now, they are also created when "new" slave receives updates from "old" master.
-
- 10 Feb, 2006 1 commit
-
-
jmiller@mysql.com authored
-
- 30 Jan, 2006 1 commit
-
-
aelkin@mysql.com authored
BUG#13227 test case to examine that local slave's triggers that use select work ok even if they fire for replicated update.
-
- 22 Dec, 2005 1 commit
-
-
lars@mysql.com authored
This includes both code and test cases.
-
- 11 Dec, 2005 1 commit
-
-
aivanov@mysql.com authored
error message if database is changed.
-
- 10 Nov, 2005 1 commit
-
-
anozdrin@mysql.com authored
checks on trigger activation)
-
- 15 Aug, 2005 2 commits
-
-
monty@mysql.com authored
Fixed failing test
-
monty@mysql.com authored
This allows us to use statement replication with functions and triggers The following things are fixed with this patch: - NOW() and automatic timestamps takes the value from the main event for functions and triggers (which allows these to replicate with statement level logging) - No side effects for triggers or functions with auto-increment values(), last_insert_id(), rand() or found_rows() - Triggers can't return result sets Fixes bugs: #12480: NOW() is not constant in a trigger #12481: Using NOW() in a stored function breaks statement based replication #12482: Triggers has side effects with auto_increment values #11587: trigger causes lost connection error
-