- 29 Mar, 2019 6 commits
-
-
Eugene Kosov authored
rec_get_offsets() was previously called in a btr_cur_optimistic_update()
-
Eugene Kosov 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 14 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.
-
Sergei Golubchik authored
automatic BuildRequires for source RPM: for every FILEPATH and "Have library XXX" cached variable, detect what rpm package it comes from and add it to the list of dependencies. That is, the source RPM will BuildRequire all those packages that were found by cmake when the source RPM was built. Presumably, our CMakeLists.txt won't check for libraries that aren't needed for a build. It supports libraries/executables/files found with FIND_LIBRARY FIND_FILE FIND_PROGRAM CHECK_LIBRARY_EXISTS
-
Sergei Golubchik authored
create source RPM cpack-way when building binary packages, this source rpm will use same BUILD_CONFIG and WITH_SSL values that were used when creating the source RPM. Only do it for a reasonably new cmake, where source rpms are known to work (3.10.2 is ok, 3.5.2 is not). And force a shorter CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX so that a source rpm could be built from a standard location in /usr/src
-
Sergei Golubchik authored
instead remove internal modules from Requires/Provides
-
Sergei Golubchik authored
add defensive $ for filenames, don't include .gitattributes and *.rpm, correct rules for *.gz and *.zip
-
Sergei Golubchik authored
since long we use a different workaround, our own CPackRPM wrapper
-
Sergei Golubchik authored
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
-
Sergei Golubchik authored
-
Vladislav Vaintroub authored
Fix mariabackup to crash if opening tablespace fails, insitead of continuing after an error.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In a Ubuntu Xenial build environment, the compiler identified as g++-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 seems to be emitting incorrect code for the compilation unit trx0rec.cc, triggering a bogus-looking AddressSanitizer report of an invalid read of something in the function trx_undo_rec_get_pars(). This is potentially affecting any larger tests where the InnoDB purge subsystem is being exercised. When the optimization level of trx0rec.cc is limited to -O1, no bogus failure is being reported. With -O2 or -O3, a lot of things seemed to be inlined in the function, and the disassembly of the generated code did not make sense to me.
-
Sujatha Sivakumar authored
select from I_S Problem: ======== When applier thread tries to access 'variable_name' of INFORMATION_SCHEMA.SESSION_VARIABLES table through triggers, it results in an abnormal exit of slave server. Analysis: ======== At the time of replication of stored routines and triggers, their associated security context will be sent by the master. The applier thread on the slave server will use this information to set the required security context for the execution of stored routines and triggers. This is achieved as follows. ->The stored routine object has a member named 'm_security_ctx' which holds the security context received from master. ->The applier thread's security_ctx is stored into a 'backup' object. ->Set the applier thread's security_ctx to 'm_security_ctx'. ->Upon the completion of stored routine execution restore the original security context of applier thread from the backup. During the above process the 'm_security_ctx' object is not initialized properly. Hence the 'external_user' of 'm_security_ctx' has invalid value for this variable and accessing this variable results in abnormal exit of server. Fix: === Invoke the Security_context::init() call from the constructor of stored routine so that 'm_security_ctx' gets initialized properly.
-
- 26 Mar, 2019 9 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Item_cond::eval_not_null_tables(): Use Item::eval_const_cond(), just like Item_cond::fix_fields(). This inconsistency was found while merging to 10.3, where the Microsoft compiler is configured to report an error for comparing longlong to bool.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Before MDEV-12113 (MariaDB Server 10.1.25), on shutdown InnoDB would write the current LSN to the first page of each file of the system tablespace. This is incompatible with MariaDB's InnoDB table encryption, because encryption repurposed the field for an encryption key ID and checksum. buf_page_is_corrupted(): For the InnoDB system tablespace, skip FIL_PAGE_FILE_FLUSH_LSN when checking if a page is all zero, because the first page of each file in the system tablespace can contain nonzero bytes in the field.
-
Alexander Barkov authored
-
- 25 Mar, 2019 3 commits
-
-
Sergey Vojtovich authored
By applying 7bd258c4.
-
Bernhard M. Wiedemann authored
unfortunately, the year 2038 problem prevented me from pushing the deadline even further into the future.
-
Daniel Bartholomew authored
-