- 02 Apr, 2019 6 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
On Microsoft Windows, InnoDB writes the path separator \ to the redo log file, while on all other platforms, / is being used. fil_name_parse(): Normalize the parsed path separators to the native format. This allows backups or data sets to be portable between Windows and other systems.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This is follow-up for commit 619d22dd to fix the cmake -DWITH_EMBEDDED_SERVER build.
-
- 01 Apr, 2019 7 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
MariaDB before MDEV-5800 in version 10.2.2 did not support indexed virtual columns. Non-persistent virtual columns were hidden from storage engines. Only starting with MDEV-5800, InnoDB would create internal metadata on virtual columns. Similar to what was done in MDEV-18084, MDEV-18090, MDEV-18960, we adjust one more code path for the old tables. innobase_build_col_map(): Allocate space for virtual columns in col_map[] but leave the entries at ULINT_UNDEFINED, noting that the virtual columns were missing before the table was being rebuilt.
-
Marko Mäkelä authored
InnoDB includes 3 parsers, which use 3 lexical analyzers that are generated with flex. Flex versions before 2.6 emitted the keyword "register", which is deprecated in C++17. The lexical analyzers were regenerated as follows: for s in storage/innobase storage/xtradb do (cd "$s"/pars; ./make_flex.sh) touch "$s"/fts/*.l make -C "$s"/fts -f Makefile.query done
-
Sergei Petrunia authored
-
Marko Mäkelä authored
The MDEV-11738/MDEV-11581 fix was supposed to add the column ROTATING_OR_FLUSHING to the INFORMATION_SCHEMA table INNODB_TABLESPACES_ENCRYPTION, but it also added that column to INNODB_TABLESPACES_SCRUBBING in InnoDB (not XtraDB). The extra column was never initialized. We will remove it, because key rotation has nothing to do with the scrubbing of tablespace data.
-
Marko Mäkelä authored
-
- 30 Mar, 2019 2 commits
-
-
Sergei Petrunia authored
It turns out, moving it to rocksdb_stress test suite is not that easy.
-
Sergei Petrunia authored
-
- 29 Mar, 2019 15 commits
-
-
Eugene Kosov authored
rec_get_offsets() was previously called in a btr_cur_optimistic_update()
-
Eugene Kosov authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Nikita Malyavin authored
* mark columns for binlog before inserting history row Closes #822
-
Sergei Golubchik authored
Clarify the error message, use the wording from the manual. Closes #870
-
Nikita Malyavin authored
Fix partitioning for trx_id-versioned tables. `partition by hash`, `range` and others now work. `partition by system_time` is forbidden. Currently we cannot use row_start and row_end in `partition by`, because insertion of versioned field is done by engine's handler, as well as row_start/row_end's value set up, which is a transaction id -- so it's also forbidden. The drawback is that it's now impossible to use `partition by key()` without parameters for such tables, because it references row_start and row_end implicitly. * add handler::vers_can_native() * drop Table_scope_and_contents_source_st::vers_native() * drop partition_element::find_engine_flag as unused * forbid versioning partitioning for trx_id as not supported * adopt vers tests for trx_id partitioning * forbid any row_end referencing in `partition by` clauses, including implicit `by key()`
-
Aleksey Midenkov authored
Fix SELECT resultset order.
-
Aleksey Midenkov authored
MDEV-15412 For any non-existing transaction ID, AS OF provides the current table contents without a warning Fail with error on non-existing TRX_ID. Closes #832
-
Ian Gilfillan authored
-
Ian Gilfillan authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Marko Mäkelä authored
When HAVE_YASSL is defined (due to cmake -DWITH_SSL=bundled or otherwise), mysys_ssl/my_crypt.cc will #include "yassl.cc" from the same directory. When MariaDB 10.2 or later is compiled with GCC 8 and optimizations are enabled, then the check if (iv) in EVP_CipherInit_ex() can be wrongly optimized away. The reason appears to be that __attribute__((nonnull)) is attached to the variable iv, because there is a (no-op) call memcpy(oiv, iv, ivlen=0) earlier in the code path. It is possible that this started failing after the code was refactored in MDEV-10332 (MariaDB 10.2.6). In MariaDB 10.1, there is a similar memcpy() call in MyCTX_nopad::init(), but the code appears to work fine.
-
- 28 Mar, 2019 8 commits
-
-
Sergei Petrunia authored
The cause for this was fix MDEV-15372, which was trying to speed up the parallel slave. Part#1: Do not attempt the "optimization" for transactions that are not replication slave workers.
-
Sujatha Sivakumar authored
Problem: ======== When attempting to delay a Slave attached with GTID, there appears to be an extra delay applied initially. For example, this output reflects a Slave that is already delayed by 43200 seconds. When switching to GTID replication, replication is paused until SQL_Remaining_Delay counts down to 0: CHANGE MASTER TO master_use_gtid=current_pos; CHANGE MASTER TO MASTER_DELAY=43200; Seconds_Behind_Master: 44847 Using_Gtid: Current_Pos SQL_Delay: 43200 SQL_Remaining_Delay: 43089 Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event Analysis: ========= When slave initiates a GTID based connection request to master, the master sends two GTID_LIST events. The first one is actual GTID_LIST event and the second one is a fake GTID_LIST event. This is sent by master to provide its current binlary log file position. The fake GTID_LIST events will have their ev->when=0. 'when' (the timestamp) is set to 0 so that slave could distinguish between real and fake Rotate events. On slave side when MASTER_DELAY is configured to "X" the applier will ensure that there is a time delay of "X" seconds before the event is applied. General behaviour of MASTER_DELAY example:- Master timestamp of event e1=10 timestamp of event e2=11 On slave MASTER_DELAY=5 Event e1 will be applied at = 15 e2 will be applied at =16 In bug scenario:- On Master: With GTIDs timestamp of event e1=10 timestamp of event e2=0 On Slave: e1 will be applied at = 10 + 5 =15 For e2, since "e2->when=0" e2->when is set to current timestamp. i.e since the e2->when and current timestamp on slave is the same applier waits for additional master_delay=5 seconds. the ev->when contributes to "rli->last_master_timestamp". rli->last_master_timestamp= ev->when + (time_t) ev->exec_time; Fake events should not update the "ev->when" to "current timestamp" on slave. Fix: === Remove the assignment of current timestamp to "ev->when" when "ev->when=0".
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
This reverts commit 21b2fada and commit 81d71ee6. 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.
-
Thirunarayanan Balathandayuthapani authored
1) Avoid writing of MLOG_INDEX_LOAD redo log record during inplace alter table when the table is empty and also for spatial index. 2) Avoid creation of temporary merge file for spatial index during index creation process.
-
Varun Gupta authored
To fix the crash there we need to make sure that the server while storing the statistical values in statistical tables should do it in a multi-byte safe way. Also there is no need to throw warnings if there is truncation while storing values from statistical fields.
-
Jan Lindström authored
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.
-
Jan Lindström authored
Pushed the decision for innodb transaction and system locking down to lock0lock.cc level. With this, we can avoid releasing these mutexes for executions where these mutexes were acquired upfront. This patch will also fix BF aborting of native threads, e.g. threads which have declared wsrep_on=OFF. Earlier, we have used, for innodb trx locks, was_chosen_as_deadlock_victim flag, for marking inodb transactions, which are victims for wsrep BF abort. With native threads (wsrep_on==OFF), re-using was_chosen_as_deadlock_victim flag may lead to inteference with real deadlock, and to deal with this, the patch has added new flag for marking wsrep BF aborts only: victim=true Similar way if replication decides to abort one of the threads we mark victim by: victim=true innobase_kill_query Remove lock sys and trx mutex handling. wsrep_innobase_kill_one_trx Mark victim trx with victim=true trx0trx.h Remove trx_abort_t type and abort type variable from trx struct. Add victim variable to trx. wsrep_kill_victim Remove abort_type lock_report_waiters_to_mysql Take also trx mutex and mark trx as a victim for replication abort. lock_trx_handle_wait_low New low level function to check whether the transaction has already been rolled back because it was selected as a deadlock victim, or if it has to wait then cancel the wait lock. lock_trx_handle_wait If transaction is not marked as victim take lock sys and trx mutex before calling lock_trx_handle_wait_low and release them after that. row_search_for_mysql Remove lock sys and trx mutex taking and releasing. trx_rollback_to_savepoint_for_mysql_low trx_commit_in_memory Clean up victim variable.
-
- 27 Mar, 2019 2 commits
-
-
Sergei Golubchik authored
MDEV-18466 Unsafe to log updates on tables referenced by foreign keys with triggers in statement format ignore FK-prelocked tables when looking for write-prelocked tables with auto-increment to complain about "Statement is unsafe because it invokes a trigger or a stored function that inserts into an AUTO_INCREMENT column"
-
Sergei Golubchik authored
special cases: * change systemd detection to use CHECK_LIBRARY_EXISTS at least once, to have it detected by build_depends.cmake * similarly, use find_library for pam * unixODBC is weird, libodbc.so is in the unixODBC package, not in the unixODBC-devel, where normally all .so files belong. Packaging bug? As a workaround, use find_file(sql.h) instead of find_path(sql.h) to make sure that /usr/include/sql.h (not /usr/include) is cached by cmake, and later build_depends.cmake will select unixODBC-devel, as a package owning /usr/include/sql.h file.
-