- 05 Oct, 2020 4 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 06 Aug, 2020 3 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
depending on build config the error might be hidded, in particular liblz4.so and libjemalloc.so make it to disappear, but with -DWITH_INNODB_LZ4=NO -DWITH_JEMALLOC=NO it reappears.
-
- 04 Aug, 2020 3 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sachin authored
Problem:- rpl_parallel2 was failing non-deterministically Analysis:- When FLUSH TABLES WITH READ LOCK is executed, it will allow all worker threads to complete their ongoing transactions and then it will pause them. At this state FTWRL will proceed to acquire global read lock. FTWRL first blocks threads from starting new commits, then upgrades the lock to block commit of existing transactions. Step1: FLUSH TABLES WITH READ LOCK - Blocks new commits Step2: * STOP SLAVE command enables 'force_abort=1' which unblocks workers, they continue to execute events. * T1: Waits in 'record_gtid' call to update 'gtid_slave_pos' table with its current GTID, but it is blocked becuase of Step1. * T2: Holds COMMIT lock and waits for T1 to commit. Step3: FLUSH TABLES WITH READ LOCK - Waiting to get BLOCK_COMMIT. This results in deadlock. When STOP SLAVE command allows paused workers to proceed, workers should skip the execution of all further events, similar to 'conservative' parallel mode. Solution:- We will assign 1 to skip_event_group when we are aborted in do_ftwrl_wait. rpl_parallel_entry->pause_sub_id is only reset when force_abort is off in rpl_pause_after_ftwrl.
-
- 03 Aug, 2020 6 commits
-
-
Elena Stepanova authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Sergei Petrunia authored
-
Sergei Golubchik authored
/home/buildbot/buildbot/build/storage/xtradb/mtr/mtr0mtr.cc:97:37: error: invalid access to non-static data member ‘fil_space_t::latch’ of NULL object [-Werror=invalid-offsetof]
-
Elena Stepanova authored
-
- 02 Aug, 2020 8 commits
-
-
Elena Stepanova authored
-
Elena Stepanova authored
Make sure system tables aren't open, as the test kills the server
-
Sergei Golubchik authored
-
Elena Stepanova authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
- 01 Aug, 2020 4 commits
-
-
Marko Mäkelä authored
Sorry, this should have been pushed instead of 7f4c749d to 10.3. (The push of d63631c3 prevented required an extra merge of that fix. And that commit was merged to 10.4 da78e952.)
-
Marko Mäkelä authored
On MariaDB 10.4 (commit 4db4b773), the query results would not be sorted, which creates random result differences. Let us explicitly sort the results already in 10.3 in order to avoid future merge trouble.
-
Marko Mäkelä authored
On MariaDB 10.4 (commit 4db4b773), the query results would not be sorted, which creates random result differences. Let us explicitly sort the results already in 10.3 in order to avoid future merge trouble.
-
Alexander Barkov authored
- Adding optional qualifiers to data types: CREATE TABLE t1 (a schema.DATE); Qualifiers now work only for three pre-defined schemas: mariadb_schema oracle_schema maxdb_schema These schemas are virtual (hard-coded) for now, but may turn into real databases on disk in the future. - mariadb_schema.TYPE now always resolves to a true MariaDB data type TYPE without sql_mode specific translations. - oracle_schema.DATE translates to MariaDB DATETIME. - maxdb_schema.TIMESTAMP translates to MariaDB DATETIME. - Fixing SHOW CREATE TABLE to use a qualifier for a data type TYPE if the current sql_mode translates TYPE to something else. The above changes fix the reported problem, so this script: SET sql_mode=ORACLE; CREATE TABLE t2 AS SELECT mariadb_date_column FROM t1; is now replicated as: SET sql_mode=ORACLE; CREATE TABLE t2 (mariadb_date_column mariadb_schema.DATE); and the slave can unambiguously treat DATE as the true MariaDB DATE without ORACLE specific translation to DATETIME. Similar, SET sql_mode=MAXDB; CREATE TABLE t2 AS SELECT mariadb_timestamp_column FROM t1; is now replicated as: SET sql_mode=MAXDB; CREATE TABLE t2 (mariadb_timestamp_column mariadb_schema.TIMESTAMP); so the slave treats TIMESTAMP as the true MariaDB TIMESTAMP without MAXDB specific translation to DATETIME.
-
- 31 Jul, 2020 10 commits
-
-
Oleksandr Byelkin authored
In case of NATURAL JOIN / USING mark all field (one table can not be opened in any case so optimisation does not worth it). IMHO table should be checked for used fields and filled after prepare, when we will fave whole info about used fields but it is too big change for a bugfix. Which will be made later by Serg patch
-
Marko Mäkelä authored
-
Thirunarayanan Balathandayuthapani authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Thirunarayanan Balathandayuthapani authored
- Adding lock_wait_timeout value as 1 make sure that truncate table fails instead of making MDL timeout.
-
Marko Mäkelä authored
The purpose of the InnoDB doublewrite buffer is to make InnoDB tolerant against cases where the server was killed in the middle of a page write. (In Linux, killing a process may interrupt a write system call, typically on a 4096-byte boundary.) There may exist multiple copies of a page number in the doublewrite buffer. Recovery should choose the latest valid copy of the page. By design, the FIL_PAGE_LSN must not precede the latest checkpoint LSN nor be later than the end of the recovered log. For page_compressed and encrypted pages, we were missing proper consistency checks. In the 10.4 data set generated for in MDEV-23231, the data file contained a valid page_compressed page, and an identical copy of that page was also present in the doublewrite buffer. But, recovery would incorrectly consider the page invalid and restore an uncompressed copy of the same page that had been written before the log checkpoint. (In fact, no redo log was to be applied to that page.) buf_dblwr_process(): Validate the FIL_PAGE_LSN in the doublewrite buffer pages, and always skip page 0, because those pages should have been recovered by Datafile::restore_from_doublewrite() if necessary. Datafile::restore_from_doublewrite(): Choose the latest applicable page from the doublewrite buffer. recv_dblwr_t::find_page(): Also validate encrypted or page_compressed pages. recv_dblwr_t::validate_page(): New function to validate a page, either a copy in a data file or in the doublewrite buffer. Also validate encrypted or page_compressed pages. This is joint work with Thirunarayanan Balathandayuthapani.
-
Marko Mäkelä authored
row_vers_impl_x_locked_low(): clust_offsets may point to memory that is allocated by mem_heap_alloc() and may have been freed. For initializing clust_offsets, try to use the stack-allocated buffer instead of a pointer that may point to freed memory. This fixes a regression that was introduced in commit f0aa073f (MDEV-20950).
-
Nikita Malyavin authored
MDEV-18042 Server crashes upon adding a non-null date column under NO_ZERO_DATE with ALGORITHM=INPLACE accept table_name and db_name instead of table_share in make_truncated_value_warning
-
Nikita Malyavin authored
Call mark_columns_per_binlog_row_image before find_row() to set up table->vcol_set early, so the virtual column value will be updated after record read (ha_rnd_pos/ha_index_next/etc) by table->update_virtual_fields() call
-
- 30 Jul, 2020 2 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
MDEV-22521 Server crashes in traverse_role_graph_up or Assertion `user' fails in traverse_role_graph_impl
-