- 29 Aug, 2024 2 commits
-
-
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
Added missing method of Item_static_float_func
-
- 28 Aug, 2024 2 commits
-
-
Oleksandr Byelkin authored
--quick-max-column-width parameter added to limit field width in --quick mode.
-
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
-
- 27 Aug, 2024 2 commits
-
-
Marko Mäkelä authored
-
Yuchen Pei authored
Also restored a change that resulted in off-by-one, as well as appending the correctly indexed key_hint.
-
- 26 Aug, 2024 6 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>
-
Kristian Nielsen authored
Before doing mark_start_commit(), check that there is no pending deadlock kill. If there is a pending kill, we won't commit (we will abort, roll back, and retry). Then we should not mark the commit as started, since that could potentially make the following GCO start too early, before we completed the commit after the retry. This condition could trigger in some corner cases, where InnoDB would take temporarily table/row locks that are released again immediately, not held until the transaction commits. This happens with dict_stats updates and possibly auto-increment locks. Such locks can be passed to thd_rpl_deadlock_check() and cause a deadlock kill to be scheduled in the background. But since the blocking locks are held only temporarily, they can be released before the background kill happens. This way, the kill can be delayed until after mark_start_commit() has been called. Thus we need to check the synchronous indication rgi->killed_for_retry, not just the asynchroneous thd->killed. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-
- 21 Aug, 2024 3 commits
-
-
Monty authored
One cause of the slowdown is because the ftruncate call can be much slower on some systems. ftruncate() is called by Aria for internal temporary tables, tables created by the optimizer, when the upper level asks Aria to delete the previous result set. This is needed when some content from previous tables changes. I have now changed Aria so that for internal temporary tables we don't call ftruncate() anymore for maria_delete_all_rows(). I also had to update the Aria repair code to use the logical datafile size and not the on-disk datafile size, which may contain data from a previous result set. The repair code is called to create indexes for the internal temporary table after it is filled. I also replaced a call to mysql_file_size() with a pwrite() in _ma_bitmap_create_first(). Reviewer: Sergei Petrunia <sergey@mariadb.com> Tester: Dave Gosselin <dave.gosselin@mariadb.com>
-
Oleksandr Byelkin authored
removed duplicated methods
-
Oleksandr Byelkin authored
Missed method added.
-
- 20 Aug, 2024 1 commit
-
-
Marko Mäkelä authored
In commit 232d7a5e we almost got the detection logic right. However, the XGETBV instruction would crash if Linux was started up with the option noxsave. have_vpclmulqdq(): Check for the XSAVE flag at the correct position and also for the AVX flag. This was tested on Ubuntu 22.04 by starting up its Linux 5.15 kernel with and without the noxsave option.
-
- 19 Aug, 2024 5 commits
-
-
Oleksandr Byelkin authored
Added missed methods to Item_string child.
-
Oleksandr Byelkin authored
Missing methods added to Item_bin_string
-
Monty authored
This is needed as the order of rows are not deterministic, especially in future versions of table statistics.
-
Monty authored
The original code is correct. valgrind and asan binaries should be built with a specialiced version of mem_root that makes it easier to find memory overwrites. This is what the BUILD scripts is doing. The specialiced mem_root code allocates a new block for every allocation which is visiable for any test that depenmds on the default original malloc size and usage.
-
Dmitry Shulga authored
Running an UPDATE statement in PS mode and having positional parameter(s) bound with an array of actual values (that is prepared to be run in bulk mode) results in incorrect behaviour in presence of on update trigger that also executes an UPDATE statement. The same is true for handling a DELETE statement in presence of on delete trigger. Typically, the visible effect of such incorrect behaviour is expressed in a wrong number of updated/deleted rows of a target table. Additionally, in case UPDATE statement, a number of modified rows and a state message returned by a statement contains wrong information about a number of modified rows. The reason for incorrect number of updated/deleted rows is that a data structure used for binding positional argument with its actual values is stored in THD (this is thd->bulk_param) and reused on processing every INSERT/UPDATE/DELETE statement. It leads to consuming actual values bound with top-level UPDATE/DELETE statement by other DML statements used by triggers' body. To fix the issue, reset the thd->bulk_param temporary to the value nullptr before invoking triggers and restore its value on finishing its execution. The second part of the problem relating with wrong value of affected rows reported by Connector/C API is caused by the fact that diagnostics area is reused by an original DML statement and a statement invoked by a trigger. This fact should be take into account on finalizing a state of diagnostics area on completion running of a statement. Important remark: in case the macros DBUG_OFF is on, call of the method Diagnostics_area::reset_diagnostics_area() results in reset of the data members m_affected_rows, m_statement_warn_count. Values of these data members of the class Diagnostics_area are used on sending OK and EOF messages. In case DML statement is executed in PS bulk mode such resetting results in sending wrong result values to a client for affected rows in case the DML statement fires a triggers. So, reset these data members only in case the current statement being processed is not run in bulk mode.
-
- 15 Aug, 2024 2 commits
-
-
Tim van Dijen authored
-
Marko Mäkelä authored
-
- 14 Aug, 2024 1 commit
-
-
Marko Mäkelä authored
The #pragma that was removed in commit e255837e (MDEV-34266) turns out to be necessary for silencing all cases of -Wstringop-truncation.
-
- 13 Aug, 2024 1 commit
-
-
Thirunarayanan Balathandayuthapani authored
- Added plugin_debug.test, multiple_index.test to innodb_fts suite from mysql-5.7. - commit c5b28e55 removes the warning for InnoDB rebuilding table to add FTS_DOC_ID - multiple_index test case has MATCH(a) values are smaller than in MySQL because ROLLBACK updates the stat_n_rows. - st_mysql_ftparser_boolean_info structure conveys boolean metadata to mysql search engine for every word in the query. This structure misses the position value to store the correct offset of every word. So phrase search queries in plugin_debug test case with boolean mode for simple parser throws wrong result.
-
- 12 Aug, 2024 4 commits
-
-
Julius Goryavsky authored
With wsrep_sst_rsync, node goes into endless loop when trying to establish connection to donor for IST/SST if the database is bind on specific IP address, not the "*". This commit fixes this problem. Separate tests are not required - the problem can occur in normal configurations on a number of systems when selecting a bing address other than "*", especially on FreeBSD and with the IPv6 addresses.
-
Jan Lindström authored
int wsrep_thd_append_key(THD*, const wsrep_key*, int, Wsrep_service_key_type) CREATE TABLE [SELECT|REPLACE SELECT] is CTAS and idea was that we force ROW format. However, it was not correctly enforced and keys were appended before wsrep transaction was started. At THD::decide_logging_format we should force used stmt binlog format to ROW in CTAS case and produce a warning if used binlog format was not ROW. At ha_innodb::update_row we should not append keys similarly as in ha_innodb::write_row if sql_command is SQLCOM_CREATE_TABLE. Improved error logging on ::write_row, ::update_row and ::delete_row if wsrep key append fails. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Alexander Barkov authored
A mixture of a multi-byte *TEXT column and a short binary column produced a too large column. For example, COALESCE(tinytext_utf8mb4, short_varbinary) produced a BLOB column instead of an expected TINYBLOB. - Adding a virtual method Type_all_attributes::character_octet_length(), returning max_length by default. - Overriding Item_field::character_octet_length() to extract the octet length from the underlying Field. - Overriding Item_ref::character_octet_length() to extract the octet length from the references Item (e.g. as VIEW fields). - Fixing Type_numeric_attributes::find_max_octet_length() to take the octet length using the new method character_octet_length() instead of accessing max_length directly.
-
Ian Gilfillan authored
-
- 09 Aug, 2024 1 commit
-
-
Oleksandr Byelkin authored
-
- 08 Aug, 2024 6 commits
-
-
Vladislav Vaintroub authored
Let perror produce OS error messages in English
-
Vladislav Vaintroub authored
fprintf() on Windows, when used on unbuffered FILE*, writes bytewise. This can make crash handler messages harder to read, if they are mixed up with other error log output. Fixed , on Windows, by using a small buffer for formatting, and fwrite instead of fprintf, if buffer is large enough for message.
-
Vladislav Vaintroub authored
The reason is that on Windows, OpenSSL can be built with different C runtime than the server (e.g Debug runtime in debug vcpkg build). Overwriting only malloc(), with CRT that server is using can cause mixup of incompatible malloc() and free() inside openssl. To fix, overwrite all memory functions.
-
Vladislav Vaintroub authored
Usually it is not needed, but sometimes we need to testing interoperability, e.g OpenSSL server / SCHANNEL client, or WolfSSL server / OpenSSL client.
-
Vladislav Vaintroub authored
For named pipe, server and client are on the same machine, and opt_local_infile just adds unnecessary copying via "load data local infile"
-
Daniel Bartholomew authored
-
- 07 Aug, 2024 2 commits
-
-
Nikita Malyavin authored
Assertion `table->field[0]->ptr >= table->record[0] && table->field[0]->ptr <= table->record[0] + table->s->reclength' failed in handler::assert_icp_limitations. table->move_fields has some limitations: 1. It cannot be used in cascade 2. It should always have a restoring pair. Rule 1 is covered by assertions in handler::assert_icp_limitations and handler::ptr_in_record (commit 30894fe9). Rule 2 should be manually maintained with care. Hopefully, the rule 1 assertions may sometimes help as well. In ha_myisam::repair, both rules are broken. table->move_fields is used asymmetrically there: it is set on every param->fix_record call (i.e. in compute_vcols) but is restored only once, in the end of repair. The reason to updating field ptr's for every call is that compute_vcols can (supposedly) be called in parallel, that is, with the same table, but different records. The condition to "unmove" the pointers in ha_myisam::restore_vcos_after_repair is incorrect, when stored vcols are available, and myisam stores a VIRTUAL field if it's the only field in the table (the record cannot be of zero length). This patch solves the problem by "unmoving" the pointers symmetrically, in compute_vcols. That is, both rules will be preserved maintained.
-
Yuchen Pei authored
-
- 04 Aug, 2024 2 commits
-
-
Jan Lindström authored
Test improvements only to make test more robust. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-
Jan Lindström authored
Modified node config with longer timeouts for suspect, inactive, install and wait_prim timeout. Increased node_1 weight to keep it primary component when other nodes are voted out. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
-