- 13 Nov, 2020 2 commits
-
-
Marko Mäkelä authored
The fix of MDEV-23456 (commit b1009ae5) introduced a livelock between page flushing and a thread that is executing buf_page_create(). buf_page_create(): If the current mini-transaction is holding an exclusive latch on the page, do not attempt to acquire another one, and do not care about any I/O fix. mtr_t::have_x_latch(): Replaces mtr_t::get_fix_count(). dyn_buf_t::for_each_block(const Functor&) const: A new variant. rw_lock_own(): Add a const qualifier. Reviewed by: Thirunarayanan Balathandayuthapani
-
Igor Babaev authored
Due to a premature cleanup of the unit that specified a recursive CTE used in the second operand of union the server fell into an infinite loop in the reported test case. In other cases this premature cleanup could cause other problems. The bug is the result of a not quite correct fix for MDEV-17024. The unit that specifies a recursive CTE has to be cleaned only after the cleanup of the last external reference to this CTE. It means that cleanups of the unit triggered not by the cleanup of a external reference to the CTE must be blocked. Usage of local table chains in selects to get external references to recursive CTEs was not correct either because of possible merges of some selects. Also fixed a minor bug in st_select_lex::set_explain_type() that caused typing 'RECURSIVE UNION' instead of 'UNION' in EXPLAIN output for external references to a recursive CTE.
-
- 12 Nov, 2020 1 commit
-
-
Sujatha authored
Analysis: ======== Writes to 'rli->log_space_total' needs to be synchronized, otherwise both SQL_THREAD and IO_THREAD can try to modify the variable simultaneously resulting in incorrect rli->log_space_total. In the current test scenario SQL_THREAD is trying to decrement 'rli->log_space_total' in 'purge_first_log' and IO_THREAD is trying to increment the 'rli->log_space_total' in 'queue_event' simultaneously. Hence test occasionally fails with result mismatch. Fix: === Convert 'rli->log_space_total' variable to atomic type.
-
- 11 Nov, 2020 5 commits
-
-
Marko Mäkelä authored
-
Daniel Bartholomew authored
-
Marko Mäkelä authored
As noted in commit 0b66d3f7, MariaDB does not support CREATE TABLESPACE for InnoDB. Hence, some code that was added in commit fec844ac and originally in mysql/mysql-server@c71dd213bd434c0579e454ab8880e6d3756b0fb0 is unused in MariaDB and should be removed.
-
Marko Mäkelä authored
trx_undo_left(): Return 0 in case of an overflow, instead of returning a negative number interpreted as a large positive number. Also, add debug assertions to check that the pointer is within the page area. This should allow us to catch bugs like MDEV-24096 easier in the future.
-
Marko Mäkelä authored
The function ibuf_merge_or_delete_for_page() was always being invoked with update_ibuf_bitmap=true ever since commit cd623508 fixed up something after MDEV-9566. Furthermore, the parameter page_size is never being passed as a null pointer, and therefore it should better be a reference to a constant object.
-
- 10 Nov, 2020 2 commits
-
-
Anel Husakovic authored
- Patch is solving generating report on warning To repeat the error run single worker: ``` ./mtr --mysqld=--lock-wait-timeout=-xx 1st 1st --force --parallel 1 ``` or `N` workers with `N+1` tests with failures and `force` ``` ./mtr --mysqld=--lock-wait-timeout=-xx 1st 1st grant5 --force --parallel 2 ``` - Patch is doing cosmetic fix of `current_test` log file which holds the old log value of test `CURRENT TEST:..` in `mark_log()` in case of `unknown option` and as such the logic which is using it's content doesn't output valid log content and doesn't generate valid `$test->{'comment'}` message.asdf - Closing the socket/handler after the removing the handler from IO for consistency Reviewed by: serg@mariadb.com
-
Marko Mäkelä authored
The row_log_t::mutex is a mutex, yet it was instrumented as rw-lock in PERFORMANCE_SCHEMA.
-
- 09 Nov, 2020 4 commits
-
-
Igor Babaev authored
This bug could manifest itself for a query with WHERE condition containing top level OR formula such that each conjunct contained a single-range condition supported by the same index. One of these range conditions must be fully covered by another range condition that is used later in the OR formula. Additionally at least one of these condition should be ANDed with a sargable range condition supported by a different index. There were several attempts to fix related problems for OR conditions after the backport of range optimizer code from MySQL (commit 0e19f3e3). Unfortunately the first of these fixes contained typo remained unnoticed until recently. This typo bug led to rejection of valid range accesses. This patch fixed this typo bug. The fix revealed another two bugs: one in a constructor for SEL_ARG, the other in the function tree_or(). Both are fixed in this patch.
-
Sergei Petrunia authored
Add a testcase.
-
Sergei Petrunia authored
Part#1: Revert the patch that caused it: commit 291be494 Author: Igor Babaev <igor@askmonty.org> Date: Thu Sep 24 22:02:00 2020 -0700 MDEV-23811: With large number of indexes optimizer chooses an inefficient plan
-
Marko Mäkelä authored
The instrumentation that was added in commit 90635c6f (MDEV-7620) was effectively reverted in MariaDB Server 10.2.2, in commit 2e814d47 (which stopped reporting the statistics) and commit fec844ac (which stopped updating the statistics). Let us remove the orphan data members to reduce the memory footprint.
-
- 05 Nov, 2020 2 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
- mysqlnd from PHP < 7.3 - mysql-connector-python any version - mysql-connector-java any version Relaxed check about garbage at the end of the packet in case of no parameters. Added check for array binding. Fixed test according to the new paradigm (allow junk at the end of the packet)
-
- 04 Nov, 2020 1 commit
-
-
Alice Sherepa authored
-
- 03 Nov, 2020 3 commits
-
-
Daniel Bartholomew authored
-
Daniele Sciascia authored
Changed the test so that it does not rely on specific auto increment ids. With Galera's default wsrep_auto_increment_control setting it is not guaranteed that auto increments always start from 1. The test was occasionally failing due to result content mismatch. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Jan Lindström authored
-
- 02 Nov, 2020 4 commits
-
-
Marko Mäkelä authored
C++11 is allowed only starting with MariaDB Server 10.4.
-
Marko Mäkelä authored
This follows up commit commit 94a520dd and commit 7c5519c1. After these changes, the default test suites on a cmake -DWITH_UBSAN=ON build no longer fail due to passing null pointers as parameters that are declared to never be null, but plenty of other runtime errors remain.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This was missed in commit d6ea03fa.
-
- 01 Nov, 2020 1 commit
-
-
Sergei Petrunia authored
-
- 31 Oct, 2020 2 commits
-
-
Daniel Black authored
Add --system={all, users, plugins, udfs, servers, stats, timezones} This will dump system information from the server in a logical form like: * CREATE USER * GRANT * SET DEFAULT ROLE * CREATE ROLE * CREATE SERVER * INSTALL PLUGIN * CREATE FUNCTION "stats" is the innodb statistics tables or EITS and these are dumped as INSERT/REPLACE INTO statements without recreating the table. "timezones" is the collection of timezone tables which are important to transfer to generate identical results on restoration. Two other options have an effect on the SQL generated by --system=all. These are mutually exclusive of each other. * --replace * --insert-ignore --replace will include "OR REPLACE" into the logical form like: * CREATE OR REPLACE USER ... * DROP ROLE IF EXISTS (MySQL-8.0+) * CREATE OR REPLACE ROLE ... * UNINSTALL PLUGIN IF EXISTS (10.4+) ... (before INSTALL PLUGIN) * DROP FUNCTION IF EXISTS (MySQL-5.7+) * CREATE OR REPLACE [AGGREGATE] FUNCTION * CREATE OR REPLACE SERVER --insert-ignore uses the construct " IF NOT EXISTS" where supported in the logical syntax. 'CREATE OR REPLACE USER' includes protection against being run as the same user that is importing the mysqldump. Includes experimental support for dumping mysql-5.7/8.0 system tables and exporting logical SQL compatible with MySQL. Updates mysqldump man page, including this information and (removing obsolute bug reference) Reviewed-by: anel@mariadb.org
-
Elena Stepanova authored
-
- 30 Oct, 2020 5 commits
-
-
Marko Mäkelä authored
This regression was introduced in commit afc9d00c. This is a partial backport of commit 199863d7 from 10.4.
-
Marko Mäkelä authored
-
Varun Gupta authored
MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare The issue here was the system variable max_sort_length was being applied to decimals and it was truncating the value for decimals to the number of bytes set by max_sort_length. This was leading to a buffer overflow as the values were written to the buffer without truncation and then we moved the offset to the number of bytes(set by max_sort_length), that are needed for comparison. The fix is to not apply max_sort_length for fixed size types like INT, DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and BLOBS.
-
Sergei Golubchik authored
cmake has caught up and since version 3.18 it started supporting CPACK_RPM_POST_TRANS_SCRIPT_FILE, something we've supported for two years and cmake 2.8.11. Both implementation add %posttrans tag and rpmbuild gets confused. Disable our implementation for cmake 3.18+
-
Jan Lindström authored
Test itself is not deterministic.
-
- 29 Oct, 2020 8 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
Use 9 byte (min length packet)
-
Oleksandr Byelkin authored
-
Sergei Golubchik authored
and restore the test modified in the same commit (the non-replication related deadlock will be reported separately)
-
Sergei Golubchik authored
Implement a different fix for "MDEV-19232: Floating point precision / value comparison problem" Instead of truncating decimal values after every division, truncate them for comparison purposes. This reverts commit 62d73df6 but keeps the test.
-
Sergei Golubchik authored
followup for 3e807d25 and eae10a87
-
Oleksandr Byelkin authored
-
Lawrin Novitsky authored
In case of direct execution(stmtid=-1, mariadb_stmt_execute_direct in C API) application is in control of how many parameters client sends to the server. In case this number is not equal to actual query parameters number, the server may start to interprete packet data incorrectly, e.g. starting from the size of null bitmap. And that could cause it to crash at some point. The commit introduces some additional COM_STMT_EXECUTE packet sanity checks: - checking that "types sent" byte is set, and the value is equal to 1. if it's not direct execution, then that value is 0 or 1. - checking that parameter type value is a valid type, and parameter flags value is 0 or only "unsigned" bit is set - added more checks that read does not go beyond the end of the packet
-