- 05 Sep, 2024 1 commit
-
-
Thirunarayanan Balathandayuthapani authored
- Remove the usage of alter_algorithm variable and disable the persistent statistics in alter_copy_bulk test case.
-
- 04 Sep, 2024 1 commit
-
-
Marko Mäkelä authored
log_t::resize_write(): Advance log_sys.resize_lsn and reset the resize_log offset to START_OFFSET whenever the memory-mapped buffer would wrap around. Previously, in case the initial target offset would be beyond the requested innodb_log_file_size, we only adjusted the offset but not the LSN. An incorrect LSN would cause log_sys.buf_free to be out of bounds when the log resizing completes. The log_sys.lsn_lock will cover the entire duration of replicating memory-mapped log for resizing. We just need a mutex that is compatible with the caller holding log_sys.latch. While the choice of mtr_t::finisher (for normal log writes) depends on mtr_t::spin_wait_delay, replicating the log during resizing is a rare operation where we can afford possible additional context switching overhead.
-
- 03 Sep, 2024 1 commit
-
-
Julius Goryavsky authored
-
- 02 Sep, 2024 2 commits
-
-
Jan Lindström authored
MDEV-31173 : Server crashes when setting wsrep_cluster_address after adding invalid value to wsrep_allowlist table Problem was that wsrep_schema tables were not marked as category information. Fix allows access to wsrep_schema tables even when node is detached. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Julius Goryavsky authored
-
- 01 Sep, 2024 11 commits
-
-
Jan Lindström authored
Replication of MyISAM and Aria DML is experimental and best effort only. Earlier change make INSERT SELECT on both MyISAM and Aria to replicate using TOI and STATEMENT replication. Replication should happen only if user has set needed wsrep_mode setting. Note: This commit contains additional changes compared to those already made for the 10.5 branch. + small refactoring after main fix. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Jan Lindström authored
* Fixes galera.galera_bf_kill_debug test case. * Enable galera_ssl_upgrade, galera_ssl_reload, galera_pc_bootstrap * Add MDEV to disabled tests that miss it P.S. This commit contains additional changes compared to the similar commit for 10.5 branch. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Denis Protivensky authored
After closing https://github.com/codership/galera-bugs/issues/947, Galera now correctly certifies table-level keys, which made bulk insert work again. The corresponding MTR test is made deterministic and re-enabled. Requires Galera 26.4.19 Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Julius Goryavsky authored
-
Jan Lindström authored
* Fixes galera.galera_bf_kill_debug test case. * Enable galera_ssl_upgrade, galera_ssl_reload, galera_pc_bootstrap * Add MDEV to disabled tests that miss it Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Jan Lindström authored
Based on logs SST was started before donor reached Primaty state. Add wait_conditions to make sure that nodes reach Primary state before starting next node. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Alexey Yurchenko authored
generate consistent error messages, Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Alexey Yurchenko authored
For TOI events specifically we have a situation where in case of the same error different nodes may generate different messages. This may be for two reasons: - different locale setting between the current client session and server default (we can reasonably require server locales to be identical on all nodes, but user can change message locale for the session) - non-deterministic course of STATEMENT execution e.g. for ALTER TABLE On the other hand we may reasonably expect TOI event failures since they are executed after replication, so we must ensure that voting is consistent. For that purpose error codes should be sufficiently unique and deterministic for TOI event failures as DDLs normally deal with a single object, so we can merely use MySQL error codes to vote on. Notice that this problem does not happen with regular transactional writesets, since the originator node will always vote success and replica nodes are assumed to have the same global locale setting. As such different error messages indicate different errors even if the error code is the same (e.g. ER_DUP_KEY can happen on different rows tables). Use only MySQL error code (without the error message) for error voting in case of TOI event failure. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Alexey Yurchenko authored
error condition (SST failure), so it should set error code before exiting. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Alexey Yurchenko authored
use grep with -a option. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Teemu Ollakka authored
When handling fatal signal, shut down Galera networking before printing out stack trace and writing core file. This is to achieve fail-silent semantics on crashes which may keep the process running for a long time, but not fully responding e.g. due to core dumping or symbol resolving. Also suppress all Galera/wsrep logging to avoid logging from background threads to garble crash information from signal handler. Notice that for fully fail-silent crash, Galera 26.4.19 is needed. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
- 30 Aug, 2024 2 commits
-
-
Julius Goryavsky authored
-
Igor Babaev authored
This bug was fixed by the patch for bug MDEV-26402. Only a test case that failed before this patch was applied is added in this commit.
-
- 29 Aug, 2024 8 commits
-
-
Marko Mäkelä authored
The recent commit 4ca355d8 (MDEV-33894) caused a serious regression for online InnoDB ib_logfile0 resizing, breaking crash-safety unless the memory-mapped log file interface is being used. However, the log resizing was broken also before this. To prevent such regressions in the future, we extend the test innodb.log_file_size_online with a kill and restart of the server and with some writes running concurrently with the log size change. When run enough many times, this test revealed all the bugs that are being fixed by the code changes. log_t::resize_start(): Do not allow the resized log to start before the current log sequence number. In this way, there is no need to copy anything to the first block of resize_buf. The previous logic regarding that was incorrect in two ways. First, we would have to copy from the last written buffer (buf or flush_buf). Second, we failed to ensure that the mini-transaction end marker bytes would be 1 in the buffer. If the source ib_logfile0 had wrapped around an odd number of times, the end marker would be 0. This was occasionally observed when running the test innodb.log_file_size_online. log_t::resize_write_buf(): To adjust for the resize_start() change, do not write anything that would be before the resize_lsn. Take the buffer (resize_buf or resize_flush_buf) as a parameter. Starting with commit 4ca355d8 we no longer swap buffers when rewriting the last log block. log_t::append(): Define as a static function; only some debug assertions need to refer to the log_sys object. innodb_log_file_size_update(): Wake up the buf_flush_page_cleaner() if needed, and wait for it to complete a batch while waiting for the log resizing to be completed. If the current LSN is behind the resize target LSN, we will write redundant FILE_CHECKPOINT records to ensure that the log resizing completes. If the buf_pool.flush_list is empty or the buf_flush_page_cleaner() is stuck for some reason, our wait will time out in 5 seconds, so that we can periodically check if the execution of SET GLOBAL innodb_log_file_size was aborted. Previously, we could get into a busy loop here while the buf_flush_page_cleaner() would remain idle.
-
Jan Lindström authored
MDEV-31173 : Server crashes when setting wsrep_cluster_address after adding invalid value to wsrep_allowlist table Problem was that wsrep_schema tables were not marked as category information. Fix allows access to wsrep_schema tables even when node is detached. This is 10.4-10.9 version of fix. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Jan Lindström authored
MDEV-33997 : Assertion `((WSREP_PROVIDER_EXISTS_ && this->variables.wsrep_on) && wsrep_emulate_bin_log) || mysql_bin_log.is_open()' failed in int THD::binlog_write_row(TABLE*, bool, const uchar*) Problem was that we did not found that table was partitioned and then we should find what is actual underlaying storage engine. We should not use RSU for !InnoDB tables. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Oleksandr Byelkin authored
Fix MDEV-34704 typos.
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
Added missing method of Item_static_float_func
-
Marko Mäkelä authored
-
- 28 Aug, 2024 4 commits
-
-
Oleksandr Byelkin authored
--quick-max-column-width parameter added to limit field width in --quick mode.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
recv_recovery_from_checkpoint_start(): Abort startup due to log corruption if we were unable to parse the entire log between the latest log checkpoint and the corresponding FILE_CHECKPOINT record. Also, reduce some code bloat related to log output and log_sys.mutex. Reviewed by: Debarun Banerjee
-
Marko Mäkelä authored
In commit fa8a46eb (MDEV-33613) the parameter innodb_lru_flush_size ceased to have any effect. Let us declare the parameter as deprecated and additionally as MARIADB_REMOVED_OPTION, so that there will be a warning written to the error log in case the option is specified in the command line. Let us also do the same for the parameter innodb_purge_rseg_truncate_frequency that was deprecated&ignored earlier in MDEV-32050. Reviewed by: Debarun Banerjee
-
- 27 Aug, 2024 5 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Let us avoid EXTENDED in the CHECK TABLE after a defragmentation, because it would occasionally report an orphan delete-marked record in the index "third". That error does not seem to be reproducible when using the regular OPTIMIZE TABLE. Also, let us make the test --repeat safe by removing the defragmentation related statistics after DROP TABLE. The defragmentation feature was removed in later releases in commit 7ca89af6 (MDEV-30545) along with this test case.
-
Yuchen Pei authored
Also restored a change that resulted in off-by-one, as well as appending the correctly indexed key_hint.
-
Marko Mäkelä authored
purge_sys_t::stop_FTS(): Fix an incorrect debug assertion that commit d58734d7 added. The assertion would fail if there had been prior invocations of purge_sys.stop_SYS() without purge_sys.resume_SYS(). The intention of the assertion is to check that number of pending stop_FTS() stays below 65536.
-
- 26 Aug, 2024 5 commits
-
-
Kristian Nielsen authored
The test was expecting the I/O thread to be in a specific state, but thread scheduling may cause it to not yet have reached that state. So just have a loop that waits for the expected state to occur. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
Kristian Nielsen authored
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
Kristian Nielsen authored
Remove the test for MDEV-14528. This is supposed to test that parallel replication from pre-10.0 master will update Seconds_Behind_Master. But after MDEV-12179 the SQL thread is blocked from even beginning to fetch events from the relay log due to FLUSH TABLES WITH READ LOCK, so the test case is no longer testing what is was intended to. And pre-10.0 versions are long since out of support, so does not seem worthwhile to try to rewrite the test to work another way. The root cause of the test failure is MDEV-34778. Briefly, depending on exact timing during slave stop, the rli->sql_thread_caught_up flag may end up with different value. If it ends up as "true", this causes Seconds_Behind_Master to be 0 during next slave start; and this caused test case timeout as the test was waiting for Seconds_Behind_Master to become non-zero. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
Kristian Nielsen authored
Depending on timing, an extra event run could start just when the event scheduler is shut down and delay running until after the table has been dropped; this would cause the test to fail with a "table does not exist" error in the log. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
Kristian Nielsen authored
(Revert a change done by mistake when XtraDB was removed.) Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-