An error occurred fetching the project authors.
- 20 Mar, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 16 Mar, 2009 1 commit
-
-
Leonard Zhou authored
The problem is issued because we set wrong start position and stop position of query string into binlog. That two values are stored as part of head info of query string. When we parse binlog, we first get position values then get the query string according position values. But seems that two values are not calculated correctly after the parse of Yacc. We don't want to touch so much of yacc because it may influence other codes. So just add one space after 'INTO' key word when parsing. This can easily resolve the problem.
-
- 05 Mar, 2009 1 commit
-
-
He Zhenxing authored
Backporting patch to 5.0.
-
- 24 Feb, 2009 1 commit
-
-
Andrei Elkin authored
-
- 21 Feb, 2009 1 commit
-
-
Alfranio Correia authored
If secure-file-priv was set on slave, it became unable to execute LOAD DATA INFILE statements sent from master using mixed or statement-based replication. This patch fixes the issue by ignoring this security restriction and checking if the files are created and read by the slave in the --slave-load-tmpdir while executing the SQL Thread.
-
- 20 Feb, 2009 1 commit
-
-
Andrei Elkin authored
Signed integer format specifier forced to print the binlog header with server_id negative if the unsigned value sets the sign-bit ON. Fixed with correcting the specifier to correspond to typeof(server_id) == ulong.
-
- 10 Feb, 2009 1 commit
-
-
Ignacio Galarza authored
- Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length
-
- 04 Feb, 2009 2 commits
-
-
Andrei Elkin authored
fixing build issue, caused by the previous push.
-
Andrei Elkin authored
The bug happened because filtering-out a STMT_END_F-flagged event so that the transaction COMMIT finds traces of incomplete statement commit. Such situation is only possible with ndb circular replication. The filtered-out rows event is one that immediately preceeds the COMMIT query event. Fixed with deploying an the rows-log-event statement commit at executing of the transaction COMMIT event. Resources that were allocated by other than STMT_END_F-flagged event of the last statement are clean up prior execution of the commit logics.
-
- 22 Jan, 2009 1 commit
-
-
Andrei Elkin authored
It's a regression issue. The reason of the bug appeared to be an error introduced into 5.1 source code. A piece of code in Create_file_log_event::do_apply_event() did not have test coverage which made make test and pb unaware. Fixed with inverting the old value of the return value from Create_file_log_event::do_apply_event(). The rpl test suite is extended with `rpl_cross_version' the file to hold regression cases similar to the current.
-
- 14 Jan, 2009 1 commit
-
-
He Zhenxing authored
The next number (AUTO_INCREMENT) field of the table for write rows events are not initialized, and cause some engines (innodb) not correctly update the tables's auto_increment value. This patch fixed this problem by honor next number fields if present.
-
- 09 Jan, 2009 1 commit
-
-
Sven Sandberg authored
Problem: when the server reads a log_event from file, it should read the post-header lengths from the format_description_log_event. Some event types which currently have post-header length 0 did not do this, and instead had a hard-coded zero length for the post-header. That means the current server version will not be able to read future versions of these events. Fix: make the reader functions read the post-header.
-
- 29 Dec, 2008 1 commit
-
-
Sven Sandberg authored
Problem: When an Incident_log_event contains a bad incident number on disk, the server crashes with an assertion. Fix: Don't validate input with assertions. Use errors.
-
- 16 Dec, 2008 1 commit
-
-
Davi Arnaut authored
Related to operator precedence and associativity. Make the expressions as explicit as possible.
-
- 10 Nov, 2008 1 commit
-
-
Build Team authored
since Oct 1st
-
- 20 Oct, 2008 1 commit
-
-
Mats Kindahl authored
In certain situations, a scan of the table will return the error code HA_ERR_RECORD_DELETED, and this error code is not correctly caught in the Rows_log_event::find_row() function, which causes an error to be returned for this case. This patch fixes the problem by adding code to either ignore the record and continuing with the next one, the the event of a table scan, or change the error code to HA_ERR_KEY_NOT_FOUND, in the event that a key lookup is attempted.
-
- 07 Oct, 2008 1 commit
-
-
Ramil Kalimullin authored
ha_statistic_increment for rpl_temporary Problem: in some cases master send a special event to reconnecting slave to keep slave's temporary tables (see #17284) and they still have references to the "old" SQL slave thread and use them to access thread's data. Fix: set temporary tables thread references to the actual SQL slave thread in such cases.
-
- 02 Oct, 2008 1 commit
-
-
Mats Kindahl authored
The Blackhole engine did not support row-based replication since the delete_row(), update_row(), and the index and range searching functions were not implemented. This patch adds row-based replication support for the Blackhole engine by implementing the two functions mentioned above, and making the engine pretend that it has found the correct row to delete or update when executed from the slave SQL thread by implementing index and range searching functions. It is necessary to only pretend this for the SQL thread, since a SELECT executed on the Blackhole engine will otherwise never return EOF, causing a livelock.
-
- 28 Sep, 2008 1 commit
-
-
He Zhenxing authored
Rotate event is automatically generated and written when rotating binary log or relay log. Rotate events for relay logs are usually ignored by slave SQL thread becuase they have the same server id as that of the slave. However, if --replicate-same-server-id is enabled, rotate event for relay log would be treated as if it's a rotate event from master, and would be executed by slave to update the rli->group_master_log_name and rli->group_master_log_pos to a wrong value and cause the MASTER_POS_WAIT function to fail and return NULL. This patch fixed this problem by setting a flag bit (LOG_EVENT_RELAY_LOG_F) in the event to tell the SQL thread to ignore these Rotate events generated for relay logs. This patch also added another binlog event flag bit (LOG_EVENT_ARTIFICIAL_F) to distinquish faked events, the method used before this was by checking if log_pos was zero.
-
- 26 Sep, 2008 1 commit
-
-
He Zhenxing authored
In order to improve the performance when replicating to partitioned myisam tables with row-based format, the number of rows of current rows log event is estimated and used to setup storage engine for bulk inserts.
-
- 03 Sep, 2008 1 commit
-
-
Andrei Elkin authored
The replication filtering rules were inappropiately applied when executing BINLOG pseudo-query. The rules are supposed to be active only at times when the slave's sql thread executes an event. Fixed with correcting a condition to call replication rules only if the slave sql thread executes the event.
-
- 26 Aug, 2008 1 commit
-
-
He Zhenxing authored
-
- 25 Aug, 2008 1 commit
-
-
Alexander Barkov authored
- fixing double problem on big endian machines - modifying regex_replace to replace negative numbers Previously only positive numbers where replaced.
-
- 22 Aug, 2008 1 commit
-
-
Alexander Barkov authored
Exchanging "m_cols" and "m_cols_ai". Very confusing variable naming :(
-
- 21 Aug, 2008 1 commit
-
-
Alexander Barkov authored
- Implementing --base64-format=decode-rows, to display SQL-alike decoded row events without their BINLOG statements. - Adding --base64-format=decode-rows into tests when calling mysqlbinlog to avoid non-deterministic results - Removing resetting of last_table_id in "RESET MASTER", which appeared to be dangerous.
-
- 20 Aug, 2008 1 commit
-
-
Alexander Barkov authored
Implementing -v command line parameter to mysqlbinlog to decode and print row events. mysql-test/include/mysqlbinlog_row_engine.inc mysql-test/r/mysqlbinlog_row.result mysql-test/r/mysqlbinlog_row_big.result mysql-test/r/mysqlbinlog_row_innodb.result mysql-test/r/mysqlbinlog_row_myisam.result mysql-test/r/mysqlbinlog_row_trans.result mysql-test/t/mysqlbinlog_row.test mysql-test/t/mysqlbinlog_row_big.test mysql-test/t/mysqlbinlog_row_innodb.test mysql-test/t/mysqlbinlog_row_myisam.test mysql-test/t/mysqlbinlog_row_trans.test Adding tests client/Makefile.am Adding new files to symlink client/mysqlbinlog.cc Adding -v option sql/log_event.cc Impelentations of the new methods sql/log_event.h Declaration of the new methods and member sql/mysql_priv.h Adding new function prototype sql/rpl_tblmap.cc Adding pre-processor conditions sql/rpl_tblmap.h Adding pre-processor conditions sql/rpl_utility.h Adding pre-processor conditions sql/sql_base.cc Adding reset_table_id_sequence() function. sql/sql_repl.cc Resetting table_id on "RESET MASTER" .bzrignore Ignoring new symlinked files
-
- 31 Jul, 2008 1 commit
-
-
He Zhenxing authored
The problem of this bug is that we need to get the list of tables to be updated for a multi-table update statement, which requires to open all the tables referenced by the statement and resolve all the fields involved in update in order to figure out the list of tables for update. However if there are replicate filter rules, some tables might not exist on slave and result in a failure before we could examine the filter rules. I think the whole problem can not be solved on slave alone, the master must record and send the information of tables involved for update to slave, so that the slave do not need to open all the tables referenced by the multi-table update statement to figure out which tables are involved for update. So a status variable is added to Query_log event to store the value of table map for update on master. And on slave, it will try to get the value of this variable and use it to examine filter rules without opening any tables on slave, if this values is not available, the old approach is used and thus the bug will still occur for when replicating from old masters.
-
- 07 Jul, 2008 1 commit
-
-
Mats Kindahl authored
On certain kinds of errors (e.g., out of stack), a call to Item_func_ set_user_var::fix_fields() might fail. Since the return value of this call was not checked inside User_var_log_event::exec_event(), continuing execution after this will cause a crash inside Item_func_set_user_var:: update_hash(). The bug is fixed by aborting execution of the event with an error if fix_fields() fails, since it is not possible to continue execution anyway.
-
- 12 May, 2008 1 commit
-
-
mats@mats-laptop.(none) authored
When flushing tables, there were a slight chance that the flush was occuring between processing of two table map events. Since the tables are opened one by one, it might result in that the tables were not valid and that sub- sequent locking of tables would cause the slave to crash. The problem is solved by opening and locking all tables at once using simple_open_n_lock_tables(). Also, the patch contain a change to open_tables() so that pre-locking only takes place when the trg_event_map is not zero, which was not the case before (this caused the lock to be placed in thd->locked_tables instead of thd->lock since the assumption was that triggers would be called later and therefore the tables should be pre-locked).
-
- 02 Apr, 2008 1 commit
-
-
sven@riska.(none) authored
Problem: a typo in the code. When autocommit, foreign_key_checks, sql_auto_is_null, or unique_checks changes, it prints "SET", and then a comma-separated list of assignments. However, it does not print the assignment to the @@autocommit variable. Fix: print the @@autocommit variable.
-
- 28 Mar, 2008 1 commit
-
-
mats@mats-laptop.(none) authored
The bug allow multiple executing transactions working with non-transactional to interfere with each others by interleaving the events of different trans- actions. Bug is fixed by writing non-transactional events to the transaction cache and flushing the cache to the binary log at statement commit. To mimic the behavior of normal statement-based replication, we flush the transaction cache in row- based mode when there is no committed statements in the transaction cache, which means we are committing the first one. This means that it will be written to the binary log as a "mini-transaction" with just the rows for the statement. Note that the changes here does not take effect when building the server with HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before this patch either. For row-based logging, we also have that when AUTOCOMMIT=1, the code now always generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the case of non-transactional changes in a statement that was rolled back. Note that for the case where changes to a non-transactional table causes a rollback due to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even though some changes has been committed to the non-transactional table.
-
- 18 Mar, 2008 1 commit
-
-
svoj@mysql.com/april.(none) authored
-
- 07 Mar, 2008 1 commit
-
-
sven@riska.(none) authored
Problem: in mixed and statement mode, a query that refers to a system variable will use the slave's value when replayed on slave. So if the value of a system variable is inserted into a table, the slave will differ from the master. Fix: mark statements that refer to a system variable as "unsafe", meaning they will be replicated by row in mixed mode and produce a warning in statement mode. There are some exceptions: some variables are actually replicated. Those should *not* be marked as unsafe. BUG#34732: mysqlbinlog does not print default values for auto_increment variables Problem: mysqlbinlog does not print default values for some variables, including auto_increment_increment and others. So if a client executing the output of mysqlbinlog has different default values, replication will be wrong. Fix: Always print default values for all variables that are replicated. I need to fix the two bugs at the same time, because the test cases would fail if I only fixed one of them.
-
- 06 Mar, 2008 1 commit
-
-
aelkin/andrei@mysql1000.(none) authored
There was a failure in that show slave status displayed a wrong message when slave stopped at processing a row event inserting to a default-less column. The problem seem to have ceased after recent fixes in rbr code. However, the test was not updated to carry testing of the case commented-out. Uncommenting and editing the test. Notice, Bug#23907 is most probably a duplicate of this one.
-
- 28 Feb, 2008 1 commit
-
-
davi@mysql.com/endora.local authored
Rename client_last_error to last_error and client_last_errno to last_errno to not break connectors which use the internal net structure for error handling.
-
- 22 Feb, 2008 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
log-slave-updates and circul repl Slave SQL thread may execute one extra event when there are events skipped by slave I/O thread (e.g. originated by the same server). Whereas it was requested not to do so by the UNTIL condition. This happens because we compare with the end position of previously executed event. This is fine when there are no skipped by slave I/O thread events, as end position of previous event equals to start position of to be executed event. Otherwise this position equals to start position of skipped event. This is fixed by: - reading the event to be executed before checking if the until condition is satisfied. - comparing the start position of the event to be executed. Since we do not have the start position available, we compute it by subtracting event length from end position (which is available). - if there are no events on the event queue at the slave sql starting time, that meet until condition, we stop immediately, as in this case we do not want to wait for next event.
-
- 19 Feb, 2008 1 commit
-
-
kostja@dipika.(none) authored
a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.
-
- 31 Jan, 2008 1 commit
-
-
aelkin/elkin@koti.dsl.inet.fi authored
The error message due to lack of the default value for an extra field was not as informative as it should be. Fixed with improving the scheme of gathering, propagating and reporting errors in applying rows events. The scheme is in the following. Any kind of error of processing of a row event incidents are to be registered with my_error(). In the end Rows_log_event::do_apply_event() invokes rli->report() with the message to display consisting of all the errors. This mimics `show warnings' displaying. A simple test checks three errors in processing an event. Two hunks - a user level error and pushing it into the list - have been devoted to already fixed Bug@31702. Some open issues relating to this artifact listed on BUG@21842 page and on WL@3679. Todo: to synchronize the statement in the tests comments on Update and Delete events may not stop when an extra field does not have a default with wl@3228 spec.
-
- 30 Jan, 2008 2 commits
-
-
mkindahl@dl145h.mysql.com authored
-
sven@riska.(none) authored
Main problem: mysql 5.1 cannot read binlogs from 4.1. Subproblem 1: There is a mistake in sql_ex_info::init. The read_str() function updates its first argument to point to the next character to read. However, it is applied only to a copy of the buffer pointer, so the real buffer pointer is not updated. Fix 1: do not take a copy of the buffer pointer. The copy was needed because sql_ex_info::init does not use the const attribute on some of its arguments. So we add the const attribute, too. Subproblem 2: The first BINLOG statement is asserted to be a FORMAT_DESCRIPTION_LOG_EVENT, but 4.1 binlogs begin with START_EVENT_V3. Fix 2: allow START_EVENT_V3 too.
-