- 27 May, 2024 17 commits
-
-
Monty authored
This is to make it easier to understand why master_pos_wait() fails in mtr.
-
Monty authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Monty authored
Fixed that no tables from 'mysql' schema are included in userstat. A beneif of this is that the server is not reading statistics tables if mysql.proc or other tables in mysql is accessed.
-
Monty authored
-
Monty authored
Other changes: - Do not collect index statistics for system tables like index_stats table_stats, performance_schema, information_schema etc as the user has no control of these and the generate noise in the statistics.
-
Sergei Golubchik authored
what is done in the plugin - stays in the plugin
-
Sergei Golubchik authored
and adjust the copyright year
-
Elena Stepanova authored
-
Monty authored
This is to update the plugin to be compatible with Percona's query_response_time plugin, with some additions. Some of the tests are taken from Percona server. - Added plugins QUERY_RESPONSE_TIME_READ, QUERY_RESPONSE_TIME_WRITE and QUERY_RESPONSE_TIME_READ_WRITE. - Added option query_response_time_session_stats, with possible values GLOBAL, ON or OFF, to the query_response_time plugin. Notes: - All modules are dependent on QUERY_RESPONSE_READ_TIME. This must always be enabled if any of the other modules are used. This will be auto-enabled in the near future. - Accounting are done per statement. Stored functions are regarded as part of the original statement. - For stored procedures the accounting are done per statement executed in the stored procedure. CALL will not be accounted because of this. - FLUSH commands will not be accounted for. This is to ensure that FLUSH QUERY_RESPONSE_TIME is not part of the statistics. (This helps when testing with mtr and otherwise). - FLUSH QUERY_RESPONSE_TIME_READ and FLUSH QUERY_RESPONSE_TIME_READ only resets the corresponding status. - FLUSH QUERY_RESPONSE_TIME and FLUSH QUERY_RESPONSE_TIME_READ_WRITE or changing the value of query_response_time_range_base followed by any FLUSH of QUERY_RESPOSNSE_TIME resets all status.
-
Sergei Golubchik authored
Various help message improvements: * MySQL->MariaDB, mysqld->mariadbd, "mysqld daemon" -> "mariadbd process" * typos * don't specify defaults directly in the help message * don't say that an option is deprecated, mark is as such * missing spaces in the middle of the text etc
-
Sergei Golubchik authored
it was a no-op, plugin variables don't have dashes
-
Sergei Golubchik authored
* use new deprecated printer for all deprecated server options * restore alphabetic option sorting order * move deprecated printer from mysqld.cc to my_getopt.c * in --help print deprecation message at the end of the option help * move 'ALL' help text where it belongs - to other SET options, and with a correct indentation. * consistently end all or none command-line option help strings with a dot - my_print_help() needs that. It's about 50/50 now, so let's do none, less line wraps in --help * remove trailing spaces from command-line option help strings
-
Christian Gonzalez authored
Currently there are mechanism to mark a system variable as deprecated, but they are only used to print warning messages when a deprecated variable is set. Leverage the existing mechanisms in order to make the deprecation information available at the --help output of mysqld by: * Moving the deprecation information (i.e `deprecation_substitute` attribute) from the `sys_var` class into the `my_option` struct. As every `sys_var` contains its own `my_option` struct, the access to the deprecation information remains available to `sys_var` objects. `my_getotp` functions, which works directly with `my_option` structs, gain access to this information while building the --help output. * For plugin variables, leverages the `PLUGIN_VAR_DEPRECATED` flag and set the `deprecation_substitute` attribute accordingly when building the `my_option` objects. * Change the `option_cmp` function to use the `deprecation_substitute` attribute instead of the name when sorting the options. This way deprecated options and the substitutes will be grouped together. 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.
-
Sergei Golubchik authored
-
Alexander Barkov authored
The problem seems to be fixed earlier in the MDEV-25829 stage branch. Removing the --disable_view_protocol command.
-
- 26 May, 2024 2 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 25 May, 2024 1 commit
-
-
Alexander Barkov authored
-
- 24 May, 2024 7 commits
-
-
Alexander Barkov authored
A user variable and a literal with different collation produce an illegal mix of collation error. Rewriting the script to avoid such arguments.
-
Alexander Barkov authored
-
Alexander Barkov authored
Step#3 The main patch
-
Alexander Barkov authored
Step#2 - Adding a new collation derivation level for CAST and CONVERT. Now character string cast functions: - CAST(string_expr AS CHAR) - CONVERT(expr USING charset_name) have a new collation derivation level between: - string literals - utf8 metadata functions, e.g. user() and database() Before the change these cast functions had collation derivation equal to table columns, which caused more illegal mix of collation conflicts. Note, binary string cast functions: - BINARY(expr) - CAST(string_expr AS BINARY) - CONVERT(expr USING binary) did not change their collation derivation, to preserve the behaviour of queries like these: SELECT database()=BINARY'test'; SELECT user()=CAST('root' AS BINARY); SELECT current_role()=CONVERT('role' USING binary); Derivation levels after the change look as follows: DERIVATION_IGNORABLE= 7, // Explicit NULL DERIVATION_NUMERIC= 6, // Numbers in string context, // Numeric user variables // CAST(numeric_expr AS CHAR) DERIVATION_COERCIBLE= 5, // Literals, string user variables DERIVATION_CAST= 4, // CAST(string_expr AS CHAR), // CONVERT(string_expr USING cs) DERIVATION_SYSCONST= 3, // utf8 metadata functions, e.g. user(), database() DERIVATION_IMPLICIT= 2, // Table columns, SP variables, BINARY(expr) DERIVATION_NONE= 1, // A mix (e.g. CONCAT) of two differrent collations DERIVATION_EXPLICIT= 0 // An explicit COLLATE clause
-
Alexander Barkov authored
Step#1 - Changing collation derivation for string user variables from IMPLICIT to COERCIBLE. Retionale: Without this preparatory change, switching the default collation for Unicode character sets from xxx_general_ci to uca1400_ai_ci would cause "Illegal mix of collations" errors in scenarios comparing a column with a non-default collation to a string user variable This is especially important for queries to INFORMATION_SCHEMA tables, whose columns use utf8mb3_general_ci. See the description of MDEV-25829 for more details and SQL script examples.
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
-
- 23 May, 2024 6 commits
-
-
Oleksandr Byelkin authored
-
Brandon Nesterenko authored
MDEV-33672 (10.6) added checks/tests for malformed events which end before the flags describe (which would lead to reading of un-owned memory). MDEV-7850 (11.5) extended all GTID events with a thread id at the end of the event. This GTID event extension invalidates the tests added in MDEV-33672 because the thread id is appended after the event (and thereby the event isn't cut short). This patch fixes these MDEV-33672 tests by not writing the GTID thread id when writing the Gtid events just for these tests. This preserves tests for backwards compatibility, rather than getting rid of the tests altogether.
-
Oleksandr Byelkin authored
-
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 2 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
-