- 11 Nov, 2020 3 commits
-
-
sjaakola authored
A follow-up fix, for original fix for MDEV-21577, which did not handle well temporary tables. OPTIMIZE and REPAIR TABLE statements can take a list of tables as argument, and some of the tables may be temporary. Proper handling of temporary tables is to skip them and continue working on the real tables. The bad version, skipped all tables, if a single temporary table was in the argument list. And this resulted so that FK parent tables were not scnanned for the remaining real tables. Some mtr tests, using OPTIMIZE or REPAIR for temporary tables caused regressions bacause of this, e.g. galera.galera_optimize_analyze_multi The fix in this PR opens temporary and real tables first, and in the table handling loop skips temporary tables, FK parent scanning is done only for real tables. The test has new scenario for OPTIMIZE and REPAIR issued for two tables of which one is temporary table. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
sjaakola authored
This PR fixes same issue as MDEV-21577 for TRUNCATE TABLE. MDEV-21577 fixed TOI replication for OPTIMIZE, REPAIR and ALTER TABLE operating on FK child table. It was later found out that also TRUNCATE has similar problem and needs a fix. The actual fix is to do FK parent table lookup before TRUNCATE TOI isolation and append found FK parent table names in certification key list for the write set. PR contains also new test scenario in galera_ddl_fk_conflict test where FK child has two FK parent tables and there are two DML transactions operating on both parent tables. For development convenience, new TO isolation macro was added: WSREP_TO_ISOLATION_BEGIN_IF and WSREP_TO_ISOLATION_BEGIN_ALTER macro was changed to skip the goto statement. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Daniele Sciascia authored
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
- 10 Nov, 2020 2 commits
-
-
Vladislav Vaintroub authored
-
Marko Mäkelä authored
-
- 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
-
- 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 2 commits
-
-
Sergei Petrunia authored
-
Elena Stepanova 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 12 commits
-
-
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
-
Oleksandr Byelkin authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Thanks to Varun Gupta for suggesting this. This seems to make main.innodb_ext_key,off more stable.
-
Marko Mäkelä authored
Invoking memcpy() on a NULL pointer is undefined behaviour (even if the length is 0) and gives the compiler permission to assume that the pointer is nonnull. Recent versions of GCC (starting with version 8) are more aggressively optimizing away checks for NULL pointers. This undefined behaviour would cause a SIGSEGV in the test main.func_encrypt on an optimized debug build on GCC 10.2.0.
-
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+
-
Marko Mäkelä authored
Also, revert the work-around for the test that was attempted in commit 85613a32. This issue was caught by MemorySanitizer as well as on the Microsoft Windows debug builds, thanks to /MD being used starting with 10.4. The code fix will also be applied to 10.2 because the regression was introduced in commit afc9d00c.
-
Jan Lindström authored
Test itself is not deterministic.
-
Jan Lindström authored
Disable galera_var_replicate_myisam until fixed on 10.4
-