- 13 Apr, 2021 2 commits
-
-
Marko Mäkelä authored
In commit d25f806d (MDEV-22749) the CRC-32C implementation of MariaDB was broken on some IA-32 and AMD64 builds, depending on the compiler version and build options. This was verified for IA-32 on GCC 10.2.1. Even though we try to identify the SSE4.2 extensions and the availaibility of the PCLMULQDQ instruction by executing CPUID, the fall-back code could be generated with extended instructions, because the entire file mysys/crc32/crc32c.c was being compiled with -msse4.2 -mpclmul. This would cause SIGILL on a PINSRD instruction on affected IA-32 targets (such as some Intel Atom processors). This might also affect old AMD64 processors (predating the 2007 Intel Nehalem microarchitecture), if some compiler chose to emit the offending instructions. While it is fine to pass a target-specific option to a target-specific compilation unit (like -mpclmul to a PCLMUL-specific compilation unit), that is not safe for mixed-architecture compilation units. For mixed-architecture compilation units, the correct way is to set target attributes on the target-specific functions. There does not seem to be a way to pass target attributes to function template instantiation. Hence, we must replace the ExtendImpl template with plain functions crc32_sse42() and crc32_slow(). We will also remove some inconsistency between my_crc32_implementation() and mysys_namespace::crc32::Choose_Extend(). The function crc32_pclmul_enabled() will be moved to mysys/crc32/crc32c.cc so that the detection code will be compiled without -msse4.2 -mpclmul. The AMD64 PCLMUL accelerated crc32c_3way() will be moved to a new file crc32c_amd64.cc. In this way, only a few functions that depend on -msse4.2 in mysys/crc32/crc32c.cc can be declared with __attribute__((target("sse4.2"))), and most of the file can be compiled for the generic target. Last, the file mysys/crc32ieee.cc will be omitted on 64-bit POWER, because it was dead code (no symbols were exported). Reviewed by: Vladislav Vaintroub
-
Anel Husakovic authored
- Commit 5cc2096f introduced in `10.5` changed DBI:DBD to DBD:MariaDB in this case with redudant `mysql` option. - According to database handle (dbh) and `connect` method one should follow https://metacpan.org/pod/DBD::MariaDB#Class-Methods with proper created data source name (dsn). - Adding socket precedance over port. - Adding skipping the comments when reading the `my.cnf` file. - MDEV-23016: mariadb-setpermission included
-
- 12 Apr, 2021 1 commit
-
-
Alexander Barkov authored
-
- 08 Apr, 2021 4 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 07 Apr, 2021 3 commits
-
-
Monty authored
MDEV-25334 FTWRL/Backup blocks DDL on temporary tables with binlog enabled, assertion fails in Diagnostics_area::set_error_status Fixed by adding a MDL_BACKUP_COMMIT lock before altering temporary tables whose creation was logged to binary log (in which case the ALTER TABLE must also be logged)
-
Alexander Barkov authored
Problem: The problem happened because of a conceptual flaw in the server code: a. The table level CHARSET/COLLATE clause affected all data types, including numeric and temporal ones: CREATE TABLE t1 (a INT) CHARACTER SET utf8 [COLLATE utf8_general_ci]; In the above example, the Column_definition_attributes (and then the FRM record) for the column "a" erroneously inherited "utf8" as its character set. b. The "ALTER TABLE t1 CONVERT TO CHARACTER SET csname" statement also erroneously affected Column_definition_attributes::charset for numeric and temporal data types and wrote "csname" as their character set into FRM files. So now we have arbitrary non-relevant charset ID values for numeric and temporal data types in all FRM files in the world :) The code in the server and the other engines did not seem to be affected by this flaw. Only InnoDB inplace ALTER was affected. Solution: Fixing the code in the way that only character string data types (CHAR,VARCHAR,TEXT,ENUM,SET): - inherit the table level CHARSET/COLLATE clause - get the charset value according to "CONVERT TO CHARACTER SET csname". Numeric and temporal data types now always get &my_charset_numeric in Column_definition_attributes::charset and always write its ID into FRM files: - no matter what the table level CHARSET/COLLATE clause is, and - no matter what "CONVERT TO CHARACTER SET" says. Details: 1. Adding helper classes to pass small parts of HA_CREATE_INFO into Type_handler methods: - Column_derived_attributes - to pass table level CHARSET/COLLATE, so columns that do not have explicit CHARSET/COLLATE clauses can derive them from the table level, e.g. CREATE TABLE t1 (a VARCHAR(1), b CHAR(1)) CHARACTER SET utf8; - Column_bulk_alter_attributes - to pass bulk attribute changes generated by the ALTER related code. These bulk changes affect multiple columns at the same time: ALTER TABLE ... CONVERT TO CHARACTER SET csname; Note, passing the whole HA_CREATE_INFO directly to Type_handler would not be good: HA_CREATE_INFO is huge and would need not desired dependencies in sql_type.h and sql_type.cc. The Type_handler API should use smallest possible data types! 2. Type_handler::Column_definition_prepare_stage1() is now responsible to set Column_definition::charset properly, according to the data type, for example: - For string data types, Column_definition_attributes::charset is set from the table level CHARSET/COLLATE clause (if not specified explicitly in the column definition). - For numeric and temporal fields, Column_definition_attributes::charset is set to &my_charset_numeric, no matter what the table level CHARSET/COLLATE says. - For GEOMETRY, Column_definition_attributes::charset is set to &my_charset_bin, no matter what the table level CHARSET/COLLATE says. Previously this code (setting `charset`) was outside of of Column_definition_prepare_stage1(), namely in mysql_prepare_create_table(), and was erroneously called for all data types. 3. Adding Type_handler::Column_definition_bulk_alter(), to handle "ALTER TABLE .. CONVERT TO". Previously this code was inside get_sql_field_charset() and was erroneously called for all data types. 4. Removing the Schema_specification_st parameter from Type_handler::Column_definition_redefine_stage1(). Column_definition_attributes::charset is now fully properly initialized by Column_definition_prepare_stage1(). So we don't need access to the table level CHARSET/COLLATE clause in Column_definition_redefine_stage1() any more. 5. Other changes: - Removing global function get_sql_field_charset() - Moving the part of the former get_sql_field_charset(), which was responsible to inherit the table level CHARSET/COLLATE clause to new methods: -- Column_definition_attributes::explicit_or_derived_charset() and -- Column_definition::prepare_charset_for_string(). This code is only needed for string data types. Previously it was erroneously called for all data types. - Moving another part, which was responsible to apply the "CONVERT TO" clause, to Type_handler_general_purpose_string::Column_definition_bulk_alter(). - Replacing the call for get_sql_field_charset() in sql_partition.cc to sql_field->explicit_or_derived_charset() - it is perfectly enough. The old code was redundant: get_sql_field_charset() was called from sql_partition.cc only when there were no a "CONVERT TO CHARACTER SET" clause involved, so its purpose was only to inherit the table level CHARSET/COLLATE clause. - Moving the code handling the BINCMP_FLAG flag from mysql_prepare_create_table() to Column_definition::prepare_charset_for_string(): This code is responsible to resolve the BINARY comparison style into the corresponding _bin collation, to do the following transparent rewrite: CREATE TABLE t1 (a VARCHAR(10) BINARY) CHARSET utf8; -> CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_bin); This code is only needed for string data types. Previously it was erroneously called for all data types. 6. Renaming Table_scope_and_contents_source_pod_st::table_charset to alter_table_convert_to_charset, because the only purpose it's used for is handlering "ALTER .. CONVERT". The new name is much more self-descriptive.
-
Daniel Black authored
SI_USER is, however in FreeBSD there are a couple of non-kernel user signal infomations above SI_KERNEL. Put a fallback just in case there is nothing available.
-
- 06 Apr, 2021 2 commits
-
-
Jan Lindström authored
Added handling for sql_safe_updated i.e. we disable it while we do wsrep_schema operations.
-
Monty authored
MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work This was because of a wrong test in encryption code that wrote random numbers over the LSN for pages for transactional Aria tables during repair. The effect was that after an ALTER TABLE ENABLE KEYS of a encrypted recovery of the tables would not work. Fixed by changing testing of !share->now_transactional to !share->base.born_transactional. Other things: - Extended Aria check_table() to check for wrong (= too big) LSN numbers. - If check_table() failed just because of wrong LSN or TRN numbers, a following repair table will just do a zerofill which is much faster. - Limit number of LSN errors in one check table to MAX_LSN_ERROR (10). - Removed old obsolete test of 'if (error_count & 2)'. Changed error_count and warning_count from bits to numbers of errors/warnings as this is more useful.
-
- 05 Apr, 2021 2 commits
-
-
mkaruza authored
`WSREP_CLIENT` is used as condition for starting ALTER/OPTIMIZE/REPAIR TOI. Using this condition async replicated affected DDL's will not be replicated. Fixed by removing this condition. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Daniele Sciascia authored
This patch makes the following changes around variable wsrep_on: 1) Variable wsrep_on can no longer be updated from a session that has an active transaction running. The original behavior allowed cases like this: BEGIN; INSERT INTO t1 VALUES (1); SET SESSION wsrep_on = OFF; INSERT INTO t1 VALUES (2); COMMIT; With regular transactions this would result in no replication events (not even value 1). With streaming replication it would be unnecessarily complex to achieve the same behavior. In the above example, it would be possible for value 1 to be already replicated if it happened to fill a separate fragment, while value 2 wouldn't. 2) Global variable wsrep_on no longer affects current sessions, only subsequent ones. This is to avoid a similar case to the above, just using just by using global wsrep_on instead session wsrep_on: --connection conn_1 BEGIN; INSERT INTO t1 VALUES(1); --connection conn_2 SET GLOBAL wsrep_on = OFF; --connection conn_1 INSERT INTO t1 VALUES(2); COMMIT; The above example results in the transaction to be replicated, as global wsrep_on will only affect the session wsrep_on of new connections. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
- 02 Apr, 2021 1 commit
-
-
Monty authored
MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work This was because of a wrong test in encryption code that wrote random numbers over the LSN for pages for transactional Aria tables during repair. The effect was that after an ALTER TABLE ENABLE KEYS of a encrypted recovery of the tables would not work. The test cases will be pushed into 10.5 as it requires of several changes to check table that safer not to backport.
-
- 01 Apr, 2021 1 commit
-
-
Marko Mäkelä authored
log_flush_notify(): Restore the reload of log_requests.start that was accidentally removed in commit 8c2e3259. Thanks to Elena Stepanova for a test case (repeatedly running FLUSH LOGS concurrently with InnoDB write transactions).
-
- 31 Mar, 2021 7 commits
-
-
Marko Mäkelä authored
buf_page_get_low(): Do not try to re-evict the page if it is multiply buffer-fixed. In commit 7cffb5f6 (MDEV-23399) a livelock was introduced. If multiple threads are concurrently requesting the same secondary index leaf page in buf_page_get_low() and innodb_change_buffering_debug is set, all threads would try to evict the page in a busy loop, never succeeding because the block is buffer-fixed by other threads. Thanks to Roel Van de Paar for reporting the original failure and Elena Stepanova for producing an "rr replay" trace.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Sergei Petrunia authored
rocksdb_checkpoint_request() should call FlushWAL(sync=true) (which does write-out and sync), not just SyncWAL() (which just syncs without writing out) Followup: the test requires debug sync facility (This is a backport to 10.5)
-
Sergei Petrunia authored
The code compares two query plans with identical costs, the plan with lateral is the same as one without. Introduce a small difference to cost numbers to prefer non-lateral plan in this case.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 30 Mar, 2021 13 commits
-
-
David CARLIER authored
-
Thirunarayanan Balathandayuthapani authored
- Aborting of fulltext index creation fails to remove the index from sys indexes table. When we try to reload the table definition, InnoDB fails with index count mismatch error. InnoDB should remove the index from sys indexes while rollbacking the secondary index creation.
-
Thirunarayanan Balathandayuthapani authored
- Post push to address 32-bit build failure.
-
Marko Mäkelä authored
-
Krunal Bauskar authored
memory barrier on ARM As suggested in the said JIRA ticket based on the contribution done by the community (in an attempt to optimize the spin-loop) the said approach was evaluated against MariaDB Server 10.5 and found to help improve throughput in the range of 2-5%. Note: 10.6 timing graph and model are different as home-brew mutexes are replaced with pthread mutexes. Said patch has mixed impact on 10.6 so not recommended for 10.6.
-
Thirunarayanan Balathandayuthapani authored
- Importing table operation fails to punch the hole in the filesystem when page compressed table is involved. To achieve that, InnoDB firstly punches the hole for the IOBuffer size(1MB). After that, InnoDB should write page by page when page compression is involved.
-
Marko Mäkelä authored
As pointed out by Andrei Elkin, the previous fix did not fix one race condition that may have caused the observed hang. innodb_log_flush_request(): If we are enqueueing the very first request at the same time the log write is being completed, we must ensure that a near-concurrent call to log_flush_notify() will not result in a missed notification. We guarantee this by release-acquire operations on log_requests.start and log_sys.flushed_to_disk_lsn. log_flush_notify_and_unlock(): Cleanup: Always release the mutex. log_sys_t::get_flushed_lsn(): Use acquire memory order. log_sys_t::set_flushed_lsn(): Use release memory order. log_sys_t::set_lsn(): Use release memory order. log_sys_t::get_lsn(): Use relaxed memory order by default, and allow the caller to specify acquire memory order explicitly. Whenever the log_sys.mutex is being held or when log writes are prohibited during startup, we can use a relaxed load. Likewise, in some assertions where reading a stale value of log_sys.lsn should not matter, we can use a relaxed load. This will cause some additional instructions to be emitted on architectures that do not implement Total Store Ordering (TSO), such as POWER, ARM, and RISC-V Weak Memory Ordering (RVWMO).
-
Jan Lindström authored
-
Jan Lindström authored
Add condition on trx->state == TRX_STATE_COMMITTED_IN_MEMORY in order to avoid unnecessary work. If a transaction has already been committed or rolled back, it will release its locks in lock_release() and let the waiting thread(s) continue execution. Let BF wait on lock_rec_has_to_wait and if necessary other BF is replayed. wsrep_trx_order_before If BF is not even replicated yet then they are ordered correctly. bg_wsrep_kill_trx Make sure victim_trx is found and check also its state. If state is TRX_STATE_COMMITTED_IN_MEMORY transaction is already committed or rolled back and will release it locks soon. wsrep_assert_no_bf_bf_wait Transaction requesting new record lock should be TRX_STATE_ACTIVE Conflicting transaction can be in states TRX_STATE_ACTIVE, TRX_STATE_COMMITTED_IN_MEMORY or in TRX_STATE_PREPARED. If conflicting transaction is already committed in memory or prepared we should wait. When transaction is committed in memory we held trx mutex, but not lock_sys->mutex. Therefore, we could end here before transaction has time to do lock_release() that is protected with lock_sys->mutex. lock_rec_has_to_wait We very well can let bf to wait normally as other BF will be replayed in case of conflict. For debug builds we will do additional sanity checks to catch unsupported bf wait if any. wsrep_kill_victim Check is victim already in TRX_STATE_COMMITTED_IN_MEMORY state and if it is we can return. lock_rec_dequeue_from_page lock_rec_unlock Remove unnecessary wsrep_assert_no_bf_bf_wait function calls. We can very well let BF wait here.
-
Daniel Black authored
-
Daniel Black authored
-
Vladislav Vaintroub authored
Amends 48141f3c
-
Daniel Black authored
This script is unused and unmaintained. The logic is implemented in scripts/mysql_system_tables_fix.sql that forms part of mysql_upgrade Its components: alter table mysql.user drop column `password_last_changed`, drop column `password_lifetime`, drop column `account_locked`; has a friendlier migration path coming MDEV-24122 alter table mysql.user change column `authentication_string` `auth_string` text COLLATE utf8_bin NOT NULL; Already part of scripts/mysql_system_tables_fix.sql alter table mysql.user add column `Password` char(41) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '' after `user`, add column `is_role` enum('N','Y') CHARACTER SET utf8 NOT NULL DEFAULT 'N' after `auth_string`; alter table mysql.user add column `default_role` char(80) COLLATE utf8_bin NOT NULL DEFAULT '', add column `max_statement_time` decimal(12,6) NOT NULL DEFAULT '0.000000'; corrected in MDEV-23201 to be in the right order. update mysql.user set `password`=`auth_string`, plugin='' where plugin="mysql_native_password"; Is handled in server in the function acl_load.
-
- 29 Mar, 2021 4 commits
-
-
Alexey Yurchenko authored
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Otto Kekäläinen authored
Fixes jobs: - mysql-8.0 Sid to mariadb-10.5 upgrade - mariadb.org-10.5 to mariadb-10.5 upgrade Downstream source: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/8db0e530872fea258e87533349fa83568eeed02d
-
Otto Kekäläinen authored
Fix the following Breaks/Replaces errors detected by Salsa-CI: [ERROR] mariadb-server-10.5 conflicts with mysql-client-core-8.0 files: {'/usr/bin/myisam_ftdump', '/usr/share/man/man1/myisam_ftdump.1.gz'} [ERROR] mariadb-server-10.5 conflicts with mysql-server-core-8.0 files: {'/usr/share/man/man1/mysqlbinlog.1.gz', '/usr/share/man/man1/myisamlog.1.gz', '/usr/share/man/man1/mysql_tzinfo_to_sql.1.gz', '/usr/share/man/man1/perror.1.gz', '/usr/share/man/man1/myisampack.1.gz', '/usr/bin/mysqld_safe', '/usr/share/man/man1/myisamchk.1.gz', '/usr/bin/myisamchk', '/usr/bin/mysql_secure_installation', '/usr/bin/mysqld_multi', '/usr/bin/mysql_tzinfo_to_sql', '/usr/bin/perror', '/usr/share/man/man1/mysqld_multi.1.gz', '/usr/bin/myisampack', '/usr/share/man/man1/mysqld_safe.1.gz', '/usr/bin/myisamlog', '/usr/share/man/man1/mysql_secure_installation.1.gz', '/usr/bin/mysqlbinlog'} [ERROR] mariadb-test conflicts with mysql-server-core-8.0 files: {'/usr/lib/mysql/plugin/adt_null.so', '/usr/lib/mysql/plugin/mypluglib.so'} Upstreamed from Debian packaging commits: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/9b6a67b53c2adf1bb5497d8649eb079767419835 https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/f6d5545a0241de2cda81c878a157517b83378c04 Also: - remove excess '<< ${source:Version}' on mysql-client-* and mysql-server-* - move more packages to Conflicts as it is semantically more correct than having those packages in Replaces
-
Otto Kekäläinen authored
This reverts commit 44885273. Reverting this commit is necessary to fix missing-breaks errors in the Debian packaging. The original fix was also not entirely necessary as a fix to the original problem. Partially also reverts commit e7c7f5c1 where this unsorted debian/control file was sorted.
-