- 24 May, 2024 1 commit
-
-
Oleksandr Byelkin authored
-
- 23 May, 2024 3 commits
-
-
Marko Mäkelä authored
trx_undo_mem_create_at_db_start(): Invoke recv_sys_t::recover() instead of buf_page_get_gen(), so that all undo log pages will be recovered correctly. Failure to do this could prevent InnoDB from starting up due to "Data structure corruption", or it could potentially lead to a situation where InnoDB starts up but some transactions were recovered incorrectly. recv_sys_t::recover(): Only acquire a buffer-fix on the pages, not a shared latch. This is adequate protection, because this function is only being invoked during early startup when no "users" are modifying buffer pool pages. The only writes are due to server bootstrap (the data files being created) or crash recovery (changes from ib_logfile0 being applied). buf_page_get_gen(): Assert that the function is not invoked while crash recovery is in progress, and that the special mode BUF_GET_RECOVER is only invoked during crash recovery or server bootstrap. All this should really have been part of commit 850d6173 (MDEV-32042).
-
Alexander Barkov authored
MDEV-33729 UBSAN negation of -X cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself in my_strntoll_mb2_or_mb4 The problem was introduced by MDEV-30879. The function my_strntoll_8bit() was correctly changed by MDEV-30879. The function my_strntoll_mb2_or_mb4() was not. Applying the missing change to my_strntoll_mb2_or_mb4().
-
Thirunarayanan Balathandayuthapani authored
in buf_dblwr_t::init_or_load_pages() - InnoDB fails to set the TRX_SYS_DOUBLEWRITE_SPACE_ID_STORED flag in transaction system header page while recreating the undo log tablespaces buf_dblwr_t::init_or_load_pages(): Tries to reset the space id and try to write into doublewrite buffer even when read_only mode is enabled. In srv_all_undo_tablespaces_open(), InnoDB should try to open the extra unused undo tablespaces instead of trying to creating it.
-
- 22 May, 2024 5 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This bug was found related to MDEV-34212. Some InnoDB tests, most notably innodb.table_flags,64k would occasionally fail. I am able to reproduce this locally on a MemorySanitizer build, sporadically. The following is a minimal .test file for reproducing this: --source include/have_innodb.inc SELECT @@innodb_page_size; and the .opt file: --innodb-undo-tablespaces=0 --innodb-page-size=64k --innodb-buffer-pool-size=20m This bug was revealed due to the recent commit 466ae1cf which set innodb_fast_shutdown=0 during server bootstrap in our regression test driver. Due to the bug, a write of undo page 50 in the system tablespace was discarded in buf_page_t::flush(). A subsequent InnoDB startup failed because an old version of that page would point to a freed undo log page 300. mtr_t::commit_shrink(): Only invoke fil_space_t::set_create_lsn() on undo tablespaces, which will be fully reinitialized or created from the scratch. On the system tablespace, we must only adjust the file size, to avoid writing pages that are beyond the end of the tablespace. Thanks to Thirunarayanan Balathandayuthapani for providing this fix.
-
Oleksandr Byelkin authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
innobase_end(): Do not attempt to shrink the system tablespace if innodb_read_only=ON or innodb_force_recovery>4. This fixes a regression due to commit 2d6c2f22 (MDEV-32452). This bug was caught when testing a fix of MDEV-34200, which adds SET GLOBAL innodb_fast_shutdown=0 to the test innodb.undo_upgrade.
-
- 21 May, 2024 4 commits
-
-
Sergei Golubchik authored
C/C 3.4 disables mysql_old_password by default, so add an option for the `connect` command to support specifying allowed authentication plugins (MARIADB_OPT_RESTRICTED_AUTH). use it to enable mysql_old_password when needed for testing
-
Sergei Golubchik authored
-
Sergei Golubchik authored
it no longer supports TLSv1.0
-
Oleksandr Byelkin authored
-
- 20 May, 2024 3 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
In the merge commit f9807aad there were some omissions or errors. ibuf_remove_free_page(): Return an error if the free list is corrupted when removing the change buffer on an upgrade. A special 11.0 version of commit 263932d5 would have been useful. buf_page_get_gen(): Correctly handle the case that a page was being concurrently read into the buffer pool and found out to be corrupted. This was part of commit a4cda66e but had been discarded in the merge. Because MariaDB Server 11.0 has reached its end of life as of commit 466ae1cf this fix is being applied to the 11.1 branch.
-
- 15 May, 2024 3 commits
-
-
Daniel Bartholomew authored
-
Daniel Bartholomew authored
-
Hugo Wen authored
Alternative operator name keywords like `and`, `or`, `xor`, etc., are uncommon in MariaDB and can cause obscure build errors when the GCC flag `-fno-operator-names` is applied. Description of `-fno-operator-names`: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html > Do not treat the operator name keywords `and`, `bitand`, `bitor`, > `compl`, `not`, `or` and `xor` as synonyms as keywords. Part of the build errors: /local/p4clients/pkgbuild-LdLa_/workspace/src/RDSMariaDB/sql/sql_select.cc:11171:28: error: expected ‘)’ before ‘and’ 11171 | DBUG_ASSERT(sel >= 0.0 and sel <= 1.00001); | ^~~ /local/p4clients/pkgbuild-LdLa_/workspace/src/RDSMariaDB/include/my_global.h:372:44: note: in definition of macro ‘unlikely’ 372 | #define unlikely(x) __builtin_expect(((x) != 0),0) | ^ ... The build failure is caused by using alternative operator name keywords `and` introduced in commit b66cdbd1. Replace the `and` keyword with `&&` and target on MariaDB 11.0+ branches which include the commit. All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.
-
- 13 May, 2024 5 commits
-
-
Sergei Golubchik authored
disable view protocol (DROP VIEW doesn't work very well with transactions) and cosmetic cleanups
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Petrunia authored
(Based on original patch by Oleksandr Byelkin) Multi-table DELETE can execute via "buffered" mode: at phase #1 it collects rowids of rows to be deleted, then at phase #2 in multi_delete::do_deletes() it calls handler->rnd_pos() to read rows to be deleted and deletes them. The problem occurred when phase #1 used Rowid Filter on the table that phase #2 would be deleting from. In InnoDB, h->rnd_init(scan=false) and h->rnd_pos() is an index scan over PK under the hood. So, at phase #2 ha_innobase::rnd_init() would try to use the Rowid Filter and hit an assertion inside ha_innobase::rnd_init(). Note that multi-table UPDATE works similarly but was not affected, because patch for MDEV-7487 added code to disable rowid filter for phase #2 in multi_update::do_updates(). This patch changes the approach: - It makes InnoDB not use Rowid Filter in rnd_pos() scans: it is disabled in ha_innobase::rnd_init() and enabled back in ha_innobase::rnd_end(). - multi_update::do_updates() no longer disables Rowid Filter for phase#2 as it is no longer necessary.
-
Sergei Golubchik authored
-
- 12 May, 2024 2 commits
-
-
Sergei Golubchik authored
the test failed almost always in release (but not in debug) builds with --- galera_sst_mariabackup.result +++ galera_sst_mariabackup.reject @@ -5,7 +5,7 @@ connection node_1; select @@innodb_undo_tablespaces; @@innodb_undo_tablespaces -0 +3 connection node_2; select @@innodb_undo_tablespaces; @@innodb_undo_tablespaces and [Warning] InnoDB: Cannot change innodb_undo_tablespaces=0 because previous shutdown was not with innodb_fast_shutdown=0 because mariadbd *before this test* wasn't using innodb_fast_shutdown=0 Fix the bootstrap to use innodb_fast_shutdown=0 (and the bootstrap creates a starting point for any test that uses a .cnf file) followup for cac0fc97 also, remove redundant include/have_innodb.inc
-
Sergei Golubchik authored
-
- 10 May, 2024 2 commits
-
-
Sergei Golubchik authored
and fix installation of mysql.service on buster followup for ec09c034
-
Sergei Golubchik authored
-
- 08 May, 2024 9 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
FreeBSD doesn't like it and hangs. As we don't wait for signal handler, let's disable SIGHUP in bootstrap too
-
Sergei Golubchik authored
.opt files, unlike combinations, accumulate, let's not overuse them
-
Sergei Golubchik authored
followup for 13663cb5
-
Sergei Golubchik authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
Makes easier to add new policy to the list, and merge to newer versions-
-
- 07 May, 2024 3 commits
-
-
Sergei Petrunia authored
Workaround patch: Do not remove GROUP BY clause when it has subquer(ies) in it. remove_redundant_subquery_clauses() removes redundant GROUP BY clause from queries in form: expr IN (SELECT no_aggregates GROUP BY ...) expr {CMP} {ALL|ANY|SOME} (SELECT no_aggregates GROUP BY ...) This hits problems when the GROUP BY clause itself has subquer(y/ies). This patch is just a workaround: it disables removal of GROUP BY clause if the clause has one or more subqueries in it. Tests: - subselect_elimination.test has all known crashing cases. - subselect4.result, insert_select.result are updated. Note that in some cases results of SELECT are changed too (not just EXPLAINs). These are caused by non-deterministic SQL: when running a query like: x > ANY( SELECT col1 FROM t1 GROUP BY constant_expression) without removing the GROUP BY, the executor is free to pick the value of t1.col1 from any row in the GROUP BY group (denote it $COL1_VAL). Then, it computes x > ANY(SELECT $COL1_VAL). When running the same query and removing the GROUP BY: x > ANY( SELECT col1 FROM t1) the executor will actually check all rows of t1.
-
Monty authored
The problem was two fold: - REPAIR TABLE t1 USE_FRM did not work for transactional Aria tables (Table was thought to be repaired, which it was not) which caused issues in later usage of the table. - When swapping tmp_data file to data file, sort_info files where not updated. This caused problems if there was several unique keys and there was a duplicate for the second key.
-
Galina Shalygina authored
Due to this bug a wrong result might be expected from queries with an IN subquery predicate in the WHERE clause and a derived table in the FROM clause to which split optimization could be applied. The function JOIN::fix_all_splittings_in_plan() used the value of the bitmap JOIN::sjm_lookup_tables() such as it had been left after the search for the best plan for the select containing the splittable derived table. That value could not be guaranteed to be correct. So the recalculation of this bitmap is needed to exclude the plans with key accesses from SJM lookup tables. Approved by Igor Babaev <igor@maridb.com>
-