summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.1 into 10.2Marko Mäkelä2019-08-281-1/+1
|\
| * fix clang warningsEugene Kosov2019-08-281-1/+1
| |
* | Merge 10.1 into 10.2Marko Mäkelä2019-08-121-1/+8
|\ \ | |/
| * Merge 5.5 into 10.1Marko Mäkelä2019-08-121-1/+9
| |\
| | * Document TRASH_FILL, TRASH_ALLOC, TRASH_FREEMarko Mäkelä2019-08-121-1/+9
| | |
| * | imporve clang buildEugene Kosov2019-06-253-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug Maintainer mode makes all warnings errors. This patch fix warnings. Mostly about deprecated `register` keyword. Too much warnings came from Mroonga and I gave up on it.
* | | Remove the unused function maria_cloneMarko Mäkelä2019-06-241-2/+1
| | |
* | | MDEV-19750 mysql command wrong encodingVladislav Vaintroub2019-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Restore the detection of default charset in command line utilities. It worked up to 10.1, but was broken by Connector/C. Moved code for detection of default charset from sql-common/client.c to mysys, and make command line utilities to use this code if charset was not specified on the command line.
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-06-131-0/+1
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.1Oleksandr Byelkin2019-06-121-0/+1
| |\ \ | | |/
| | * MDEV-18479 ComplementIgor Babaev2019-05-281-0/+1
| | | | | | | | | | | | | | | | | | This patch complements the patch that fixes bug MDEV-18479. This patch takes care of possible overflow when calculating the estimated number of rows in a materialized derived table / view.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-05-281-1/+9
|\ \ \ | |/ /
| * | Merge 5.5 into 10.1Marko Mäkelä2019-05-281-0/+8
| |\ \ | | |/
| | * MDEV-17799 Add ASAN-poisoned redzones for MEM_ROOTSergei Golubchik2019-05-201-5/+6
| | | | | | | | | | | | | | | | | | post-merge changes Closes #954
| | * MDEV-17799 Add ASAN-poisoned redzones for MEM_ROOT and mem_heap_tEugene Kosov2019-05-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | This patch is for MEM_ROOT only. In debug mode add 8 byte of poisoned memory before every allocated chunk. On the right of every chunk there will be either 1-7 trailing poisoned bytes, or next chunk's redzone, or poisoned non allocated memory or redzone of a malloc()ed buffer.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-05-13133-134/+134
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-11104-104/+104
| |\ \ | | |/
| | * Update FSF AddressVicențiu Ciorbaru2019-05-1183-83/+83
| | | | | | | | | | | | * Update wrong zip-code
| * | Update FSF addressVicențiu Ciorbaru2019-05-118-8/+8
| | |
| * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-1120-21/+21
| |\ \ | | |/
| | * Follow-up to changing FSF addressVicențiu Ciorbaru2019-05-118-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some places didn't match the previous rules, making the Floor address wrong. Additional sed rules: sed -i -e 's/Place.*Suite .*, Boston/Street, Fifth Floor, Boston/g' sed -i -e 's/Suite .*, Boston/Fifth Floor, Boston/g'
| | * Update FSF addressMichal Schorm2019-05-1011-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is based on the work of Michal Schorm, rebased on the earliest MariaDB version. Th command line used to generate this diff was: find ./ -type f \ -exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \ -exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-05-041-1/+1
|\ \ \ | |/ /
| * | cleanup: make TREE copyableSergei Golubchik2019-04-241-1/+1
| | | | | | | | | | | | | | | move per-object TREE::null_element to be one global static null_element.
* | | Fix wsrep_thd_is_applier macro to point correct function name.Jan Lindström2019-04-101-1/+1
| | |
* | | Merge branch '10.1' into 10.2Sergei Golubchik2019-03-291-12/+14
|\ \ \ | |/ /
| * | Revert MDEV-18464 and MDEV-12009Marko Mäkelä2019-03-281-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 21b2fada7ab7f35c898c02d2f918461409cc9c8e and commit 81d71ee6b21870772c336bff15b71904914f146a. The MDEV-18464 change introduces a few data race issues. Contrary to the documentation, the field trx_t::victim is not always being protected by lock_sys_t::mutex and trx_t::mutex. Most importantly, it seems that KILL QUERY could wrongly avoid acquiring both mutexes when invoking lock_trx_handle_wait_low(), in case another thread had already set trx->victim=true. We also revert MDEV-12009, because it should depend on the MDEV-18464 fix being present.
| * | MDEV-12009: Allow to force kill user threads/query which are flagged as high ↵Jan Lindström2019-03-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | priority by Galera As noted on kill_one_thread SUPER should be able to kill even system threads i.e. threads/query flagged as high priority or wsrep applier thread. Normal user, should not able to kill threads/query flagged as high priority (BF) or wsrep applier thread.
| * | cmake: re-enable -Werror in the maintainer modeSergei Golubchik2019-03-271-12/+14
| | | | | | | | | | | | | | | | | | now we can afford it. Fix -Werror errors. Note: * old gcc is bad at detecting uninit variables, disable it. * time_t is int or long, cast it for printf's
* | | MDEV-17262: mysql crashed on galera while node rejoined cluster (#895)sysprg2019-03-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains a fix for the MDEV-17262/17243 issues and new mtr test. These issues (MDEV-17262/17243) have two reasons: 1) After an intermediate commit, a transaction loses its status of "transaction that registered in the MySQL for 2pc coordinator" (in the InnoDB) due to the fact that since version 10.2 the write_row() function (which located in the ha_innodb.cc) does not call trx_register_for_2pc(m_prebuilt->trx) during the processing of split transactions. It is necessary to restore this call inside the write_row() when an intermediate commit was made (for a split transaction). Similarly, we need to set the flag of the started transaction (m_prebuilt->sql_stat_start) after intermediate commit. The table->file->extra(HA_EXTRA_FAKE_START_STMT) called from the wsrep_load_data_split() function (which located in sql_load.cc) will also do this, but it will be too late. As a result, the call to the wsrep_append_keys() function from the InnoDB engine may be lost or function may be called with invalid transaction identifier. 2) If a transaction with the LOAD DATA statement is divided into logical mini-transactions (of the 10K rows) and binlog is rotated, then in rare cases due to the wsrep handler re-registration at the boundary of the split, the last portion of data may be lost. Since splitting of the LOAD DATA into mini-transactions is technical, I believe that we should not allow these mini-transactions to fall into separate binlogs. Therefore, it is necessary to prohibit the rotation of binlog in the middle of processing LOAD DATA statement. https://jira.mariadb.org/browse/MDEV-17262 and https://jira.mariadb.org/browse/MDEV-17243
* | | Merge branch '10.1' into 10.2Sergei Golubchik2019-03-151-4/+4
|\ \ \ | |/ /
| * | cleanup: miscSergei Golubchik2019-03-121-4/+4
| | |
* | | MDEV-18577: Indexes problem on import dump SQLJan Lindström2019-03-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that we skipped background persistent statistics calculation on applier nodes if thread is marked as high priority (a.k.a BF). However, on applier nodes all DDL which is replicate will be executed as high priority i.e BF. Fixed by allowing background persistent statistics calculation on applier nodes even when thread is marked as BF. This could lead BF lock waits but for queries on that node needs that statistics.
* | | MDEV-14984 - regression in connect performanceSergey Vojtovich2019-03-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed redundant plugin_thdvar_cleanup() from end_connection(): called by THD::free_connection(), which always follows end_connection(). Saves at least one lock(LOCK_plugin) and one rdlock(LOCK_system_variables_hash). Benchmarked on a 2socket/20core/40threads Broadwell system using sysbench connect brencmark @40 threads (with select 1 disabled). 10.2 shows moderate improvement: 136219.93 -> 137766.31 CPS. 10.3 is improvement is somewhat better: 93018.29 -> 101379.77 CPS. Also backported MyRocks memory leak fix from 10.4, which turned out to be unrelated.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-03-071-0/+4
|\ \ \ | |/ / | | | | | | | | | | | | Rewrite the MDEV-13818 fix to prevent heap-use-after-free. Add a test case for MDEV-18272.
| * | ASAN loves stack, give it someSergei Golubchik2019-03-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes these test failures in ASAN builds (in 10.1 and 10.4): * main.signal_demo3 * main.sp * sys_vars.max_sp_recursion_depth_func * mroonga/storage.foreign_key_delete_existent * mroonga/storage.foreign_key_delete_nonexistent * mroonga/storage.foreign_key_insert_existent * mroonga/storage.foreign_key_update_existent * mroonga/storage.foreign_key_update_nonexistent * mroonga/storage.function_command_auto-escape * mroonga/storage.function_command_select * mroonga/storage.variable_enable_operations_recording_insert
| * | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a 2+ node cluster which is replicating from an async master and the binlog_format is set to STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the server node generates wrong auto_increment values, which are different from what was generated on the async master. In the title of the MDEV-9519 it was proposed to ban start slave on a Galera if master binlog_format = statement and wsrep_auto_increment_control = 1, but the problem can be solved without such a restriction. The causes and fixes: 1. We need to improve processing of changing the auto-increment values after changing the cluster size. 2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables, without waiting of the next invocation of the wsrep_view_handler_cb() callback. In the current version these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes in some scenarios. 3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, we need to add a "shadow copies" of these variables (which stores the latest values set by the user). https://jira.mariadb.org/browse/MDEV-9519
* | | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a 2+ node cluster which is replicating from an async master and the binlog_format is set to STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the server node generates wrong auto_increment values, which are different from what was generated on the async master. In the title of the MDEV-9519 it was proposed to ban start slave on a Galera if master binlog_format = statement and wsrep_auto_increment_control = 1, but the problem can be solved without such a restriction. The causes and fixes: 1. We need to improve processing of changing the auto-increment values after changing the cluster size. 2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables, without waiting of the next invocation of the wsrep_view_handler_cb() callback. In the current version these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes in some scenarios. 3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, we need to add a "shadow copies" of these variables (which stores the latest values set by the user). https://jira.mariadb.org/browse/MDEV-9519
* | | MDEV-18204 Fix rocksdb incremental backupVladislav Vaintroub2019-02-181-0/+1
| | | | | | | | | | | | | | | Fix incremental prepare to copy #rocksdb subdirectory from the incremental dir.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-02-033-4/+4
|\ \ \ | |/ / | | | | | | | | | | | | Temporarily disable a test for commit 2175bfce3e9da8332f10ab0e0286dc93915533a2 because fixing it in 10.2 requires updating libmariadb.
| * | Merge 10.1 into 10.1Marko Mäkelä2019-02-023-4/+4
| |\ \ | | | | | | | | | | | | This is joint work with Oleksandr Byelkin.
| | * \ Merge branch '5.5' into 10.0Oleksandr Byelkin2019-01-282-2/+2
| | |\ \ | | | |/
| | | * Crude "auto-load-data-local-infile" modemariadb-5.5.63Sergei Golubchik2019-01-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable LOAD DATA LOCAL INFILE suport by default and auto-enable it for the duration of one query, if the query string starts with the word "load". In all other cases the application should enable LOAD DATA LOCAL INFILE support explicitly.
| | * | Merge branch '5.5' into 10.0Oleksandr Byelkin2019-01-281-2/+2
| | |\ \ | | | |/
| | | * Avoid noisy Clang 7 warning about unused variable.Vladislav Vaintroub2019-01-191-2/+2
| | | | | | | | | | | | | | | | Patch by Eugene Kosov.
| | | * MDEV-17248 Improve ASAN memory pool instrumentationEugene Kosov2018-09-211-2/+2
| | | | | | | | | | | | | | | | | | | | alloc_root(): unpoison only requested amount of bytes instead of a possible bigger aligned-sized buffer.
* | | | Merge 10.1 into 10.2Marko Mäkelä2019-02-021-1/+3
|\ \ \ \ | |/ / /
| * | | MDEV-10963 Fragmented BINLOG queryAndrei Elkin2019-01-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was originally stated in http://bugs.mysql.com/bug.php?id=82212 The size of an base64-encoded Rows_log_event exceeds its vanilla byte representation in 4/3 times. When a binlogged event size is about 1GB mysqlbinlog generates a BINLOG query that can't be send out due to its size. It is fixed with fragmenting the BINLOG argument C-string into (approximate) halves when the base64 encoded event is over 1GB size. The mysqlbinlog in such case puts out SET @binlog_fragment_0='base64-encoded-fragment_0'; SET @binlog_fragment_1='base64-encoded-fragment_1'; BINLOG @binlog_fragment_0, @binlog_fragment_1; to represent a big BINLOG. For prompt memory release BINLOG handler is made to reset the BINLOG argument user variables in the middle of processing, as if @binlog_fragment_{0,1} = NULL is assigned. Notice the 2 fragments are enough, though the client and server still may need to tweak their @@max_allowed_packet to satisfy to the fragment size (which they would have to do anyway with greater number of fragments, should that be desired). On the lower level the following changes are made: Log_event::print_base64() remains to call encoder and store the encoded data into a cache but now *without* doing any formatting. The latter is left for time when the cache is copied to an output file (e.g mysqlbinlog output). No formatting behavior is also reflected by the change in the meaning of the last argument which specifies whether to cache the encoded data. Rows_log_event::print_helper() is made to invoke a specialized fragmented cache-to-file copying function which is copy_cache_to_file_wrapped() that takes care of fragmenting also optionally wraps encoded strings (fragments) into SQL stanzas. my_b_copy_to_file() is refactored to into my_b_copy_all_to_file(). The former function is generalized to accepts more a limit argument to constraint the copying and does not reinitialize anymore the cache into reading mode. The limit does not do any effect on the fully read cache.
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-12-131-1/+1
|\ \ \ \ | |/ / /
| * | | Merge 10.0 into 10.1Marko Mäkelä2018-12-131-1/+1
| |\ \ \ | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, apply the MDEV-17957 changes to encrypted page checksums, and remove error message output from the checksum function, because these messages would be useless noise when mariabackup is retrying reads of corrupted-looking pages, and not that useful during normal server operation either. The error messages in fil_space_verify_crypt_checksum() should be refactored separately.
View Lorry Controller Status