- 14 Sep, 2024 5 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 11 Sep, 2024 5 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
as it can never be null (only "" or "disabled")
-
Sergei Golubchik authored
-
- 10 Sep, 2024 1 commit
-
-
Yuchen Pei authored
These variables/parameters have the default read-only value of 1, and the only way to change them is through a command line flag together with a command line flag loading spider. After this change, the flag will have no effect.
-
- 05 Sep, 2024 1 commit
-
-
Libing Song authored
crash recovery Summary ======= When doing server recovery, the active transactions will be rolled back by InnoDB background rollback thread automatically. The prepared transactions will be committed or rolled back accordingly by binlog recovery. Binlog recovery is done in main thread before the server can provide service to users. If there is a big transaction to rollback, the server will not available for a long time. This patch provides a way to rollback the prepared transactions asynchronously. Thus the rollback will not block server startup. Design ====== - Handler::recover_rollback_by_xid() This patch provides a new handler interface to rollback transactions in recover phase. InnoDB just set the transaction's state to active. Then the transaction will be rolled back by the background rollback thread. - Handler::signal_tc_log_recover_done() This function is called after tc log is opened(typically binlog opened) has done. When this function is called, all transactions will be rolled back have been reverted to ACTIVE state. Thus it starts rollback thread to rollback the transactions. - Background rollback thread With this patch, background rollback thread is defered to run until binlog recovery is finished. It is started by innobase_tc_log_recovery_done().
-
- 04 Sep, 2024 3 commits
-
-
Kristian Nielsen authored
If a slave replicating an event has waited for more than @@slave_abort_blocking_timeout for a conflicting metadata lock held by a non-replication thread, the blocking query is killed to allow replication to proceed and not be blocked indefinitely by a user query. Reviewed-by: Monty <monty@mariadb.org> Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 29 Aug, 2024 7 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
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.
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
Added missing method of Item_static_float_func
-
Marko Mäkelä authored
-
- 28 Aug, 2024 8 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
-
Brandon Nesterenko authored
The option binlog_optimize_thread_scheduling was initially added to provide a safe alternative for the newly added binlog group commit logic, such that when 0, it would disable a leader thread from performing the binlog write for all transactions that are a part of the group commit. Any problems related to the binlog group commit optimization should be sorted out by now, so we can deprecate-to-eventually-remove the option altogether. This commit performs the deprecation, and the removal is tracked by MDEV-33745. Note, as the option is only able to be provided via configuration at startup time, users will not see a deprecation message unless looking through the CLI help message. Reviewed By ============ Kristian Nielsen <knielsen@knielsen-hq.org> Sergei Golubchik <serg@mariadb.org>
-
Alexander Barkov authored
Changing the alias LOCALTIME->CURRENT_TIMESTAMP to LOCALTIME->CURRENT_TIME. This changes the return type of LOCALTIME from DATETIME to TIME, according to the SQL Standard.
-
Yuchen Pei authored
This is the CS part of the implementation of MENT-2070.
-
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
-
Andrew Hutchings authored
Coding standards and PR template now reference `main`.
-
- 27 Aug, 2024 7 commits
-
-
Daniel Black authored
Add Oracular to the allowed Ubuntu names.
-
Marko Mäkelä authored
-
Oleksandr Byelkin authored
--quick-max-column-width parameter added to limit field width in --quick mode.
-
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 3 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>
-