- 11 Nov, 2020 3 commits
-
-
Marko Mäkelä authored
-
Daniel Bartholomew authored
-
Daniele Sciascia authored
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
- 10 Nov, 2020 4 commits
-
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
-
Sergei Golubchik authored
-
Sergei Petrunia authored
Adjust the testcase for MariaDB 10.3+ : prevent IN-to-subquery conversion optimization from working.
-
- 09 Nov, 2020 5 commits
-
-
Marko Mäkelä authored
MDEV-23672 (commit 7eda5561) introduced a regression that can corrupt not only undo log pages, but anything that resides in the InnoDB buffer pool. trx_undo_left(): Add debug assertions for the assumptions. If the pointer is out of bounds, we will return a positive number, not a negative one. Thus, once a page overflow occurs, further overflow to adjacent pages will be allowed. This allows us to remove some more relaxed debug assertions from some callers. trx_undo_log_v_idx(): Correctly calculate the size limit.
-
Sergei Golubchik authored
-
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
-
- 08 Nov, 2020 1 commit
-
-
Daniel Black authored
tested with: $ mysql-test/mtr --mem --mysqld=--sql-mode=ORACLE main.lock_user Observed Oracle syntax quoting difference in `SHOW CREATE USER` output only. Omission in syntax noticed by Robert Bindar. Identical to previous patch except in sql_yacc_ora.yy
-
- 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 4 commits
-
-
Daniel Black authored
Reviewed-by: vicentiu@mariadb.org
-
Daniel Black authored
The parser of CREATE USER accepts ACCOUNT LOCK before PASSWORD EXPIRE but not the other way around. This just changes the SHOW CREATE USER to output a sql syntax that is valid. Thanks to Robert Bindar for analysis.
-
Nayuta Yanagisawa authored
MDEV-18842: Unfortunate error message when the same column is used for application period start and end An application-time period must be composed of two different columns. We added a check that ensures that the above condition is met.
-
Jan Lindström authored
-
- 03 Nov, 2020 7 commits
-
-
Daniele Sciascia authored
During graceful shutdowns, client connections are closed and eventually and THD::awake() acquires LOCK_thd_data mutex which is required later on in wsrep_thd_is_aborting(). Make sure LOCK_thd_data is acquired, even if global wsrep_on is disabled. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
sjaakola authored
Some DDL statements appear to acquire MDL locks for a table referenced by foreign key constraint from the actual affected table of the DDL statement. OPTIMIZE, REPAIR and ALTER TABLE belong to this class of DDL statements. Earlier MariaDB version did not take this in consideration, and appended only affected table in the certification key list in write set. Because of missing certification information, it could happen that e.g. OPTIMIZE table for FK child table could be allowed to apply in parallel with DML operating on the foreign key parent table, and this could lead to unhandled MDL lock conflicts between two high priority appliers (BF). The fix in this patch, changes the TOI replication for OPTIMIZE, REPAIR and ALTER TABLE statements so that before the execution of respective DDL statement, there is foreign key parent search round. This FK parent search contains following steps: * open and lock the affected table (with permissive shared locks) * iterate over foreign key contstraints and collect and array of Fk parent table names * close all tables open for the THD and release MDL locks * do the actual TOI replication with the affected table and FK parent table names as key values The patch contains also new mtr test for verifying that the above mentioned DDL statements replicate without problems when operating on FK child table. The mtr test scenario #1, which can be used to check if some other DDL (on top of OPTIMIZE, REPAIR and ALTER) could cause similar excessive FK parent table locking. Reviewed-by: Aleksey Midenkov <aleksey.midenkov@mariadb.com> Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Daniel Bartholomew authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Jan Lindström authored
-
Teemu Ollakka authored
Prepared statements which were run over binary protocol crashed a server if the statement did not have CF_PS_ARRAY_BINDING_OPTIMIZED flag and the statement was executed in bulk mode and a BF abort occrurred. This was because the bulk execution resulted in several statements without calling wsrep_after_statement() between, which confused wsrep transaction state tracking. As a fix, call wsrep_after_statement() in bulk loop after each execution if CF_PS_ARRAY_BINDING_OPTIMIZED is not set. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
- 02 Nov, 2020 7 commits
-
-
Marko Mäkelä authored
instant_alter_column_possible(): Relax a too strict debug assertion. The existence of an index stub or a corrupted index on virtual columns does not imply that virtual columns exist.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
C++11 is allowed only starting with MariaDB Server 10.4.
-
Marko Mäkelä authored
-
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 3 commits
-
-
Elena Stepanova authored
-
Sergei Petrunia authored
-
Elena Stepanova authored
-
- 31 Oct, 2020 3 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
-
Oleksandr Byelkin authored
-
Elena Stepanova authored
-
- 30 Oct, 2020 1 commit
-
-
Daniel Black authored
Per b9f3f068, mysql_system_tables_data.sql creates a mysql_native_password with a salted hash of "invalid" so that `set password` will detect a native password can be applied:. SHOW CREATE USER; diligently uses this value in its output generating the SQL: MariaDB [(none)]> show create user; +---------------------------------------------------------------------------------------------------+ | CREATE USER for dan@localhost | +---------------------------------------------------------------------------------------------------+ | CREATE USER `dan`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket | +---------------------------------------------------------------------------------------------------+ Attempting to execute this before this patch results in: MariaDB [(none)]> CREATE USER `dan2`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket; ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number As such, deep the implementation of mysql_native_password we make "invalid" valid (pun intended) such that the above create user will succeed. We do this by storing "*THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE" (credit: Oracle MySQL), that is of an INCORRECT length for a scramble. In native_password_authenticate we check the length of this cached value and immediately fail if it is anything other than the scramble length. native_password_get_salt is only called in the context of set_user_salt, so all setting of native passwords to hashed content of 'invalid', quite literally create an invalid password. So other forms of "invalid" are valid SQL in creating invalid passwords: MariaDB [(none)]> set password = 'invalid'; Query OK, 0 rows affected (0.001 sec) MariaDB [(none)]> alter user dan@localhost IDENTIFIED BY PASSWORD 'invalid'; Query OK, 0 rows affected (0.000 sec) closes #1628 Reviewer: serg@mariadb.com
-