An error occurred fetching the project authors.
- 14 Oct, 2016 2 commits
-
-
Kristian Nielsen authored
The original MySQL patch left some refactoring todo's, possibly because of known conflicts with other parallel development (like info-repository feature perhaps). This patch fixes those todos/refactorings. Signed-off-by:
Kristian Nielsen <knielsen@knielsen-hq.org>
-
Kristian Nielsen authored
Initial merge of delayed replication from MySQL git. The code from the initial push into MySQL is merged, and the associated test case passes. A number of tasks are still pending: 1. Check full test suite run for any regressions or .result file updates. 2. Extend the feature to also work for parallel replication. 3. There are some todo-comments about future refactoring left from MySQL, these should be located and merged on top. 4. There are some later related MySQL commits, these should be checked and merged. These include: e134b9362ba0b750d6ac1b444780019622d14aa5 b38f0f7857c073edfcc0a64675b7f7ede04be00f fd2b210383358fe7697f201e19ac9779879ba72a afc397376ec50e96b2918ee64e48baf4dda0d37d 5. The testcase from MySQL relies heavily on sleep and timing for testing, and seems likely to sporadically fail on heavily loaded test servers in buildbot or distro build farms. Signed-off-by:
Kristian Nielsen <knielsen@knielsen-hq.org>
-
- 22 Jun, 2016 1 commit
-
-
Vicențiu Ciorbaru authored
Fix the replication failure caused by incorect initialization of THD::invoker_host && THD::invoker_user. Breakdown of the failure is this: Query_log_event::host and Query_log_event::user can have their LEX_STRING's set to length 0, but the actual str member points to garbage. Code afterwards copies Query_log_event::host and user to THD::invoker_host and THD::invoker_user. Calling code for these members expects both members to be initialized. Eg. the str member be a NULL terminated string and length have appropriate size.
-
- 04 May, 2016 1 commit
-
-
Sujatha Sivakumar authored
INSERTS/UPDATES ON TEMPORARY TABLES Bug#14294223: CHANGES NOT ALLOWED TO TEMPORARY TABLES ON READ-ONLY SERVERS Problem: ======== Running 5.5.14 in read only we can create temporary tables but can not insert or update records in the table. When we try we get Error 1290 : The MySQL server is running with the --read-only option so it cannot execute this statement. Analysis: ========= This bug is very specific to binlog being enabled and binlog-format being stmt/mixed. Standalone server without binlog enabled or with row based binlog-mode works fine. How standalone server and row based replication work: ===================================================== Standalone server and row based replication mark the transactions as read_write only when they are modifying non temporary tables as part of their current transaction. Because of this when code enters commit phase it checks if a transaction is read_write or not. If the transaction is read_write and global read only mode is enabled those transaction will fail with 'server is read only mode' error. In the case of statement based mode at the time of writing to binary log a binlog handler is created and it is always marked as read_write. In case of temporary tables even though the engine did not mark the transaction as read_write but the new transaction that is started by binlog handler is considered as read_write. Hence in this case when code enters commit phase it finds one handler which has a read_write transaction even when we are modifying temporary table. This causes the server to throw an error when global read-only mode is enabled. Fix: ==== At the time of commit in "ha_commit_trans" if a read_write transaction is found, we should check if this transaction is coming from a handler other than binlog_handler. This will ensure that there is a genuine read_write transaction being sent by the engine apart from binlog_handler and only then it should be blocked.
-
- 22 Mar, 2016 2 commits
-
-
Alexey Botchkov authored
LOG-SLOW-SLAVE-STATEMENTS NOT DISPLAYED. These parameters were moved from the command line options to the system variables section. Treatment of the opt_log_slow_slave_statements changed to let the dynamic change of the variable.
-
Sergei Golubchik authored
delete deferred events after they're executed (otherwise they can be executed again for a sub-statement) See also commit 0e78d1d Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com> Date: Wed Mar 20 11:20:47 2013 +0530 BUG#15850951-DUPLICATE ERROR IN REPLICATION WITH SLAVE TRIGGERS AND AUTO INCREMENT
-
- 21 Mar, 2016 1 commit
-
-
Sergei Golubchik authored
don't crash in debug builds. issue an error message on corrupt event
-
- 04 Mar, 2016 1 commit
-
-
Otto Kekäläinen authored
-
- 01 Mar, 2016 1 commit
-
-
Venkatesh Duggirala authored
REPLICATION Problem: In RBR mode, merge table updates are not successfully applied on a cascading replication. Analysis & Fix: Every type of row event is preceded by one or more table_map_log_events that gives the information about all the tables that are involved in the row event. Server maintains the list in RPL_TABLE_LIST and it goes through all the tables and checks for the compatibility between master and slave. Before checking for the compatibility, it calls 'open_tables()' which takes the list of all tables that needs to be locked and opened. In RBR, because of the Table_map_log_event , we already have all the tables including base tables in the list. But the open_tables() which is generic call takes care of appending base tables if the list contains merge tables. There is an assumption in the current replication layer logic that these tables (TABLE_LIST type objects) are always added in the end of the list. Replication layer maintains the count of tables(tables_to_lock_count) that needs to be verified for compatibility check and runs through only those many tables from the list and rest of the objects in linked list can be skipped. But this assumption is wrong. open_tables()->..->add_children_to_list() adds base tables to the list immediately after seeing the merge table in the list. For eg: If the list passed to open_tables() is t1->t2->t3 where t3 is merge table (and t1 and t2 are base tables), it adds t1'->t2' to the list after t3. New table list looks like t1->t2->t3->t1'->t2'. It looks like it added at the end of the list but that is not correct. If the list passed to open_tables() is t3->t1->t2 where t3 is merge table (and t1 and t2 are base tables), the new prepared list will be t3->t1'->t2'->t1->t2. Where t1' and t2' are of TABLE_LIST objects which were added by add_children_to_list() call and replication layer should not look into them. Here tables_to_lock_count will not help as the objects are added in between the list. Fix: After investigating add_children_list() logic (which is called from open_tables()), there is no flag/logic in it to skip adding the children to the list even if the children are already included in the table list. Hence to fix the issue, a logic should be added in the replication layer to skip children in the list by checking whether 'parent_l' is non-null or not. If it is children, we will skip 'compatibility' check for that table. Also this patch is not removing 'tables_to_lock_count' logic for the performance issues if there are any children at the end of the list, those can be easily skipped directly by stopping the loop with tables_to_lock_count check.
-
- 23 Feb, 2016 3 commits
-
-
Vicențiu Ciorbaru authored
-
Vicențiu Ciorbaru authored
The reason for the assertion failure is that the update statement for the minimal row image sets only the PK column in the write_set of the table to true. On the other hand, the trigger aims to update a different column. Make sure that triggers update the used columns accordingly, when being processed.
-
Daniele Sciascia authored
Fix remaining issues with wsrep_sync_wait and query cache. - Fixes misplaced call to invalidate query cache in Rows_log_event::do_apply_event(). Query cache was invalidated too early, and allowed old entries to be inserted to the cache. - Reset thd->wsrep_sync_wait_gtid on query cache hit. THD->cleanup_after_query is not called in such cases, and thd->wsrep_sync_wait_gtid remained initialized.
-
- 10 Feb, 2016 1 commit
-
-
Daniele Sciascia authored
Manually merged query cache fixes from 97c02faf0a39dd189eeda4f75fb35bc5db69d541.
-
- 09 Feb, 2016 1 commit
-
-
Sergei Golubchik authored
-
- 01 Dec, 2015 1 commit
-
-
Venkatesh Duggirala authored
Problem: ======== 1) Drop table queries are re-generated by server before writing the events(queries) into binlog for various reasons. If table name/db name contains a non regular characters (like latin characters), the generated query is wrong. Hence it breaks the replication. 2) In the edge case, when table name/db name contains 64 characters, server is throwing an assert assert(M_TBLLEN < 128) 3) In the edge case, when db name contains 64 latin characters, binlog content is interpreted badly which is leading replication failure. Analysis & Fix : ================ 1) Parser reads the table name from the query and converts it to standard charset(utf8) and stores it in table_name variable. When drop table query is regenerated with the same table_name variable, it should be converted back to the original charset from standard charset(utf8). 2) Latin character takes two bytes for each character. Limit of the identifier is 64. SYSTEM_CHARSET_MBMAXLEN is set to '3'. So there is a possiblity that tablename/dbname contains 3 * 64. Hence assert is changed to (M_TBLLEN <= NAME_CHAR_LEN*SYSTEM_CHARSET_MBMAXLEN) 3) db_len in the binlog event header is taking 1 byte. db_len is ranged from 0 to 192 bytes (3 * 64). While reading the db_len from the event, server is casting to uint instead of uchar which is leading to bad db_len. This problem is fixed by changing the cast type to uchar.
-
- 29 Nov, 2015 1 commit
-
-
Monty authored
This includes fixing all utilities to not have any memory leaks, as safemalloc warnings stopped tests from passing on MacOSX. - Ensure that all clients takes character-set-dir, as the libmysqlclient library will use it. - mysql-test-run now passes character-set-dir to all external clients. - Changed dynstr_free() so that it can be called twice (made freeing code easier) - Changed rpl_global_gtid_slave_state to be allocated dynamicly as it includes a mutex that needs to be initizlied/destroyed before my_end() is called. - Removed rpl_slave_state::init() and rpl_slave_stage::deinit() as their job are better handling by constructor and delete. - Print alias instead of table_name in check_duplicate_key as table_name may have been converted to lower case. Other things: - Fixed a case in time_to_datetime_with_warn() where we where using && instead of & in tests
-
- 10 Nov, 2015 3 commits
-
-
Monty authored
Not printing the value" with binlog-row-image=minimal" Merged Rows_log_event::print_verbose_one_row() and log_event_print_value() with MySQL 5.7 Added flush after writing of Table_map_log_event() to fix wrong order of lines in output. This causes a lot of changes in some test results.
-
Monty authored
- XA - Transaction_context_event (used by MysQL group replication) - View change event (used by MysQL group replication)
-
Monty authored
changes in query execution plans. Fixed by introducing table->rpl_write_set which holds which columns should be stored in the binary log. Other things: - Removed some not needed references to read_set and write_set to make code really changing read_set and write_set easier to read (in opt_range.cc) - Added error handling of failed unpack_current_row() - Added missing call to mark_columns_needed_for_insert() for DELAYED INSERT - Removed not used functions in_read_set() and in_write_set() - In rpl_record.cc, removed not used variable error
-
- 22 Oct, 2015 1 commit
-
-
Michael Widenius authored
THD is already available in Protocol
-
- 08 Oct, 2015 1 commit
-
-
Monty authored
MDEV-8685 MariaDB fails to decode Anonymous_GTID entries MDEV-5705 Replication testing: 5.6->10.0 - Ignoring GTID events from MySQL 5.6+ (Allows replication from MySQL 5.6+ with GTID enabled) - Added ignorable events from MySQL 5.6 - mysqlbinlog now writes information about GTID and ignorable events. - Added more information in error message when replication stops because of wrong information in binary log. - Fixed wrong test when write_on_release() should flush cache.
-
- 21 Sep, 2015 1 commit
-
-
Alexander Barkov authored
pointer instread, as the "derivation" and "repertoire" parts of DTCollation were not really used by user_var_entry.
-
- 07 Sep, 2015 1 commit
-
-
Oleksandr Byelkin authored
Backport of upstream patch. revno: 5696
-
- 04 Sep, 2015 11 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
* Start_encryption_log_event * --encrypt-binlog command line option based on google patches.
-
Sergei Golubchik authored
Introduce Log_event_writer() that encapsulates writing data to an IO_CACHE with automatic checksum calculation. Now all events properly checksum themselves as needed. Use Log_event_writer in MYSQL_BIN_LOG::write_cache() instead of copy-pasting its logic all over. Later Log_event_writer will also do encryption.
-
Sergei Golubchik authored
now when my_vsnprintf() supports %llu for a few years already.
-
Sergei Golubchik authored
introduce DBUG_DUMP_EVENT_BUF, remove few unused DBUG_EXECUTE_IF's simplify few DBUG_PRINT's remove few redundant #ifndef DBUG_OFF's
-
Sergei Golubchik authored
-
Sergei Golubchik authored
* fix unireg.h includes * use enum_binlog_checksum_alg for binlog checksum variables, not uint8
-
Sergei Golubchik authored
-
Sergei Golubchik authored
* reformat long lines * remove useless 'const' * remove unneeded do { ... } while(false} wrapper * remove unneeded method
-
Sergei Golubchik authored
There are three Log_event::read_log_event() methods: 1. read the event image from IO_CACHE into String 2. create Log_event from the in-memory event image 3. read the event image from IO_CACHE and create Log_event The 3rd was reading event image into memory and invoking the 2nd to create Log_event. Now the 3rd also uses the 1st to read the event image from IO_CACHE into memory, instead of duplicating its functionality.
-
Sergei Golubchik authored
remove my_crc_dbug_check (gdb can do it itself). use 0 instead of my_checkum(0, 0, 0) - just as 10.0 does now.
-
- 27 Aug, 2015 1 commit
-
-
Monty authored
- Part 3: Adding mem_root to push_back() and push_front() Other things: - Added THD as an argument to some partition functions. - Added memory overflow checking for XML tag's in read_xml()
-
- 21 Aug, 2015 2 commits
-
-
Monty authored
- Added mem_root to all calls to new Item - Added private method operator new(size_t size) to Item to ensure that we always use a mem_root when creating an item. This saves use once call to current_thd per Item creation
-
Sergey Vojtovich authored
Added mandatory thd parameter to Item (and all derivative classes) constructor. Added thd parameter to all routines that may create items. Also removed "current_thd" from Item::Item. This reduced number of pthread_getspecific() calls from 290 to 177 per OLTP RO transaction.
-
- 04 Aug, 2015 1 commit
-
-
Kristian Nielsen authored
This bug is essentially another variant of MDEV-7458. If a transaction conflict caused a deadlock kill of T2 in record_gtid() during commit, the code would do a rollback _before_ running rgi->unmark_start_commit(). This creates a race where following transactions could start too early (before T2 has completed its transaction retry). This in turn could lead to replication failure, if there was a conflict that caused eg. duplicate key error or similar. The fix is to remove these rollbacks (in Query_log_event::do_apply_event() and Xid_log_event::do_apply_event(). They seem out-of-place; code in log_event.cc generally does not roll back on error, this is handled higher up. In addition, because of the extreme difficulty of reproducing bugs like MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to detect (in debug builds) or prevent (in release builds) similar bugs. ha_rollback_trans() will now call unmark_start_commit() if needed (and assert in debug build when a caller does rollback without unmark first). We also add an extra check for thd->killed() so that we avoid doing mark_start_commit() if we already have a pending deadlock kill. And we add a missing unmark_start_commit() call in the error case, found by the above assertion.
-
- 31 Jul, 2015 1 commit
-
-
Sergei Golubchik authored
Cherry-pick from 10.0: commit 126523d1 Author: Sergei Golubchik <serg@mariadb.org> Date: Mon Feb 23 20:53:41 2015 +0100 MDEV-6703 Add "mysqlbinlog --binlog-row-event-max-size" support
-
- 26 Jul, 2015 1 commit
-
-
Monty authored
Fix was to add a test in Query_log_event::Query_log_event() if we are using CREATE ... SELECT and in this case use trans cache, like we do on the master. This avoid using (with doesn't have checksum) Other things: - Removed dummy call my_checksum(0L, NULL, 0) - More DBUG_PRINT - Cleaned up Log_event::need_checksum() to make it more readable (similar as in MySQL 5.6) - Renamed variable that was hiding another one in create_table_imp()
-