Commit graph

1373 commits

Author SHA1 Message Date
Monty
a1f630ccfe Fixed result for embedded server
- Revert wrongly record embedded result files. These were either
  recorded with normal server (not embedded) or an embedded server
  with not default compile option. This can be seen that the committed
  result file had replication variables which should never happen.

- Reverted back change of include/is_embedded.inc. One cannot check for
  $MYSQL_EMBEDDED as this only tells if there exists an embedded
  server, not if the current server we are testing is the embedded
  server. This could easily be verified by doing
  'mtr sys_vars.sysvars_server_embedded'. This would fail with a wrong
  result instead of being marked as skipped as --embedded was not
  used.
2022-01-28 16:31:53 +02:00
Daniel Black
68b3fa8865 MDEV-27289: mtr test for WITH_SERVER_EMBEDDED=ON reenable
mtr is checking the wrong path for the embedded executable
on out of tree builds.

The is_embedded.inc tests are also checking the version rather
than the MTR MYSQL_EMBEDDED environment variable.

As a result, a few tests are out of date in the result recordings.
2022-01-27 10:36:39 +11:00
Daniel Black
410c4edef3 MDEV-27467: innodb to enforce the minimum innodb_buffer_pool_size in SET GLOBAL
.. to be the same as startup.

In resolving MDEV-27461, BUF_LRU_MIN_LEN (256) is the minimum number of
pages for the innodb buffer pool size. Obviously we need more than just
flushing pages. Taking the 16k page size and its default minimum, an
extra 25% is needed on top of the flushing pages to make a workable buffer
pool.

The minimum innodb_buffer_pool_chunk_size (1M) restricts the minimum
otherwise we'd have a pool made up of different chunk sizes.

The resulting minimum innodb buffer pool sizes are:

Page Size, Previously minimum (startup), with change.
        4k                            5M           2M
        8k                            5M           3M
       16k                            5M           5M
       32k                           24M          10M
       64k                           24M          20M

With this patch, SET GLOBAL innodb_buffer_pool_size minimums are
enforced.

The evident minimum system variable size for innodb_buffer_pool_size
is 2M, however this is only setable if using 4k page size. As
the order of the page_size and buffer_pool_size aren't fixed, we can't
hide this change.

Subsequent changes:
* innodb_buffer_pool_resize_with_chunks.test - raised of pool resize due to new
  minimums. Chunk size also needed increase as the test was for
  pool_size < chunk_size to generate a warning.
* Removed srv_buf_pool_min_size and replaced use with MYSQL_SYSVAR_NAME(buffer_pool_size).min_val
* Removed srv_buf_pool_def_size and replaced constant defination in
  MYSQL_SYSVAR_LONGLONG(buffer_pool_size)
* Reordered ha_innodb to allow for direct use of MYSQL_SYSVAR_NAME(buffer_pool_size).min_val
* Moved buf_pool_size_align into ha_innodb to access to MYSQL_SYSVAR_NAME(buffer_pool_size).min_val
* loose-innodb_disable_resize_buffer_pool_debug is needed in the
  innodb.restart.opt test so that under debug mode, resizing of the
  innodb buffer pool can occur.
2022-01-19 11:10:45 +11:00
Jan Lindström
e32c21cb93 Changing wsrep_slave_threads parameter requires that cluster
is connected so moved test here.
2022-01-11 09:43:59 +02:00
Alexey Botchkov
efedf3da68 MDEV-22711 Assertion `nr != 0' failed in handler::update_auto_increment.
DBUG_ASSERT removed as the AUTO INCREMENT can actually be 0 when the
SET insert_id= 0; was done.
2021-10-26 00:29:27 +04:00
Nikita Malyavin
300253acf1 revive innodb_debug_sync
innodb_debug_sync was introduced in commit
b393e2cb0c and reverted in
commit fc58c17216 due to memory leak reported
by valgrind, see MDEV-21336.

The leak is now fixed by adding `rw_lock_free(&slot->debug_sync_lock)`
after background thread working loop is finished, and the patch is
reapplied, with respect to c++98 fixes by Marko.

The missing DEBUG_SYNC for MDEV-18546 in row0vers.cc is also reapplied.
2021-04-27 11:51:17 +03:00
Marko Mäkelä
56274bd5e4 MDEV-23076 Misleading "InnoDB: using atomic writes"
As suggested by Vladislav Vaintroub, let us remove misleading
and malformatted startup messages.

Even if the global variable srv_use_atomic_writes were set, we would
still invoke my_test_if_atomic_write() to check if writes are atomic
with a particular page size.

When using the default innodb_page_size=16k, page writes should be
atomic on NTFS when using ROW_FORMAT=COMPRESSED and KEY_BLOCK_SIZE<=4.

Disabling srv_use_atomic_writes when innodb_file_per_table=OFF does
not make sense, because that is a dynamic parameter.

We also correct the documentation string of innodb_use_atomic_writes
and remove the duplicate variable innobase_use_atomic_writes.
2021-03-22 18:12:44 +02:00
Marko Mäkelä
0f8caadc96 MDEV-22653: Remove the useless parameter innodb_simulate_comp_failures
The debug parameter innodb_simulate_comp_failures injected compression
failures for ROW_FORMAT=COMPRESSED tables, breaking the pre-existing
logic that I had implemented in the InnoDB Plugin for MySQL 5.1 to prevent
compressed page overflows. A much better check is already achieved by
defining UNIV_ZIP_COPY at the compilation time.
(Only UNIV_ZIP_DEBUG is part of cmake -DWITH_INNODB_EXTRA_DEBUG=ON.)
2021-03-22 18:12:44 +02:00
Sergei Golubchik
ce3a2a688d make @@wsrep_provider and @@wsrep_notify_cmd read-only
this should simplify run-time cluster management
2021-02-18 19:03:01 +01:00
Marko Mäkelä
ea9cd97f85 MDEV-24536 innodb_idle_flush_pct has no effect
The parameter innodb_idle_flush_pct that was introduced in
MariaDB Server 10.1.2 by MDEV-6932 has no effect ever since
the InnoDB changes from MySQL 5.7.9 were applied in
commit 2e814d4702.

Let us declare the parameter as deprecated and having no effect.
2021-01-13 18:55:56 +02:00
Sergei Golubchik
f6e91552f0 MDEV-4677 GROUP_CONCAT not showing any output with group_concat_max_len >= 4Gb
don't allow group_concat_max_len values >= 4Gb
(they never worked anyway)
2020-12-10 08:45:20 +01:00
Sergei Golubchik
b31912fd35 MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare
don't allow too small max_sort_length values
2020-12-10 08:45:20 +01:00
Oleksandr Byelkin
2e5450af05 Merge branch '10.1' into 10.2 2020-10-29 15:16:53 +01:00
Sergei Golubchik
d6302c9a47 MDEV-23702 calculating(auto rounding) issue
Implement a different fix for
"MDEV-19232: Floating point precision / value comparison problem"

Instead of truncating decimal values after every division,
truncate them for comparison purposes.

This reverts commit 62d73df6b2 but keeps the test.
2020-10-29 09:27:56 +01:00
Oleksandr Byelkin
65e26bc1ba Merge branch '10.1' into 10.2 2020-10-28 10:56:38 +01:00
Marko Mäkelä
42e1815ad8 MDEV-16952 Introduce SET GLOBAL innodb_max_purge_lag_wait
Let us introduce a dummy variable innodb_max_purge_lag_wait
for waiting that the InnoDB history list length is below
the user-specified limit. Specifically,

SET GLOBAL innodb_max_purge_lag_wait=0;

should wait for all history to be purged. This could be useful
when upgrading from an older version to MariaDB 10.3 or later,
to avoid hitting MDEV-15912.

Note: the history cannot be purged if there exist transactions
that may see old versions.

Reviewed by: Vladislav Vaintroub
2020-10-27 15:47:18 +02:00
Alexey Botchkov
8761571a71 MDEV-22524 SIGABRT in safe_mutex_unlock with
session_track_system_variables and max_relay_log_size.

lock LOCK_global_system_variables around the get_one_variable() call
in the Session_sysvars_tracker::store_variable().
2020-10-27 16:44:11 +04:00
Marko Mäkelä
987df9b37a MDEV-23720 Change innodb_log_optimize_ddl=OFF by default
MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization
of ALTER TABLE, which skips the writing of redo log records.
In MDEV-16809 we introduced a parameter that allows the redo log to
be written, so that Mariabackup would not be impacted, but we kept
the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON).

As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl,
implemented in MariaDB 10.5.1), omitting the redo log writes can
actually reduce performance, because we will have to wait for the data
pages to be written out. When the redo log file is configured to be
large enough, it actually can be much faster to write the redo log and
avoid the extra page flushing.

When the redo log is omitted (innodb_log_optimize_ddl=ON), also
Mariabackup may have to perform a lot of extra work, to re-copy the
entire data file if it is possible that any log was omitted during
the backup.

Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl
is deprecated and ignored. We hereby deprecate (but will not ignore)
the parameter in earlier versions as well.
2020-10-25 11:48:34 +02:00
Sergei Golubchik
15f03c2041 MDEV-23492 performance_schema_digests_size changing from default to 5000 when enabling performance_schema
max allowed value limit should be larger than any auto-sized value
2020-10-23 15:53:41 +02:00
Alexey Botchkov
94b493571a MDEV-20744 SET GLOBAL replicate_do_db = DEFAULT causes crash.
DEFAULT for the replicate_do_db is the "" as our documentation states.
2020-10-23 12:20:17 +04:00
Sujatha
43ec9370b3 MDEV-10149: sys_vars.rpl_init_slave_func fails sporadically in buildbot
problem:
========
mysqltest: In included file "./include/assert.inc":
included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 69:
Assertion text: '@@global.max_connections = @start_max_connections'
Assertion result: '0'


mysqltest: In included file "./include/assert.inc":
included from mysql-test/suite/sys_vars/t/rpl_init_slave_func.test at line 86:
Assertion text: '@@global.max_connections = @start_max_connections + 1'
Assertion result: '0'

Analysis:
=========
A slave SQL thread sets its Running state to Yes very early in its
initialisation, before the majority of initialisation actions, including
executing the init_slave command, are done. Thus the testcase has a race
condition where the initial replication setup might finish executing later
than the testcase SET GLOBAL init_slave, making the testcase see its effect
where it checks for its absence.

Fix:
===
Include 'sync_slave_sql_with_master.inc' at the beginning of the test to
ensure that slave applier has completed the execution of 'init_slave' command
and proceeded to event application. Replace the apparently needless RESET
MASTER / RESET SLAVE etc.

Patch is based on:
b91e2e6f90
Author: laurynas-biveinis
2020-10-22 07:16:29 +05:30
Marko Mäkelä
620ea816ad Merge 10.1 into 10.2 2020-10-21 14:02:04 +03:00
Marko Mäkelä
65b7f72b51 InnoDB 5.6.50
The only applicable InnoDB change to MariaDB that was made
between MySQL 5.6.49 and MySQL 5.6.50 is MDEV-23999.
2020-10-21 10:16:06 +03:00
Jan Lindström
0aef658dfa Remove unnecessary and incorrect add_suppression.
Changes to be committed:
	modified:   mysql-test/suite/sys_vars/r/wsrep_cluster_address_basic.result
	modified:   mysql-test/suite/sys_vars/t/wsrep_cluster_address_basic.test
2020-10-05 10:34:01 +03:00
Marko Mäkelä
295e2d500b MDEV-16664: Add deprecation warning for innodb_lock_schedule_algorithm=VATS
The setting innodb_lock_schedule_algorithm=VATS that was introduced
in MDEV-11039 (commit 021212b525)
causes conflicting exclusive locks to be incorrectly granted to
two transactions. Specifically, in lock_rec_insert_by_trx_age()
the predicate !lock_rec_has_to_wait_in_queue(in_lock) would hold even
though an active transaction is already holding an exclusive lock.
This was observed between two DELETE of the same clustered index record.
The HASH_DELETE invocation in lock_rec_enqueue_waiting() may be related.

Due to lack of progress in diagnosing the problem, we will deprecate the
option and issue a warning that using it may corrupt data. The unsafe
option was enabled between
commit 0c15d1a6ff (MariaDB 10.2.3)
and the parent of
commit 1cc1d0429d (MariaDB 10.2.17, 10.3.9).
2020-10-05 09:34:27 +03:00
Daniel Black
1be8ac390d Revert "[MDEV-7978] add show create user"
Appoligies, had a dirty branch before pushing:

This reverts commit 053653a23c.

This reverts commit 0ff897807f.

This reverts commit 85b085972b.

This reverts commit f3f45e46b6.

This reverts commit a470b3570a.

This reverts commit f8b8d202bc.

This reverts commit 6b6f066fdd.

This reverts commit a701e9e6c3.

This reverts commit c169838611.
2020-09-24 13:58:29 +10:00
Vicențiu Ciorbaru
053653a23c [MDEV-7978] Update test cases for sysvars_server_embedded. 2020-09-20 16:10:02 +10:00
Vicențiu Ciorbaru
a470b3570a [MDEV-7978] Update test cases
Update test to account for the new SHOW CREATE USER command.
2020-09-20 16:10:00 +10:00
Vicențiu Ciorbaru
6b6f066fdd [MDEV-7978] Update test cases
Adding an extra statement requires test cases update.
2020-09-20 16:08:40 +10:00
Aleksey Midenkov
6fa40b85be MDEV-23554 Wrong default value for foreign_key_checks variable
Sys_var_bit::session_save_default() ignored reverse_semantics property.
2020-08-25 10:15:04 +03:00
Marko Mäkelä
4c50120d14 MDEV-23474 InnoDB fails to restart after SET GLOBAL innodb_log_checksums=OFF
Regretfully, the parameter innodb_log_checksums was introduced
in MySQL 5.7.9 (the first GA release of that series) by
mysql/mysql-server@af0acedd88
which partly replaced a parameter that had been introduced in 5.7.8
mysql/mysql-server@22ba38218e
as innodb_log_checksum_algorithm.

Given that the CRC-32C operations are accelerated on many processor
implementations (AMD64 with SSE4.2; since MDEV-22669 also on IA-32
with SSE4.2, POWER 8 and later, ARMv8 with some extensions)
and by lookup tables when only generic SISD instructions are available,
there should be no valid reason to disable checksums.

In MariaDB 10.5.2, as a preparation for MDEV-12353, MDEV-19543 deprecated
and ignored the parameter innodb_log_checksums altogether. This should
imply that after a clean shutdown with innodb_log_checksums=OFF one
cannot upgrade to MariaDB Server 10.5 at all.

Due to these problems, let us deprecate the parameter innodb_log_checksums
and honor it only during server startup.
The command SET GLOBAL innodb_log_checksums will always set the
parameter to ON.
2020-08-18 16:46:07 +03:00
Marko Mäkelä
182e2d4a6c Merge 10.1 into 10.2 2020-08-13 07:38:35 +03:00
Marko Mäkelä
101ce10d0d MDEV-20672 Inconsistent usage message for innodb_compression_algorithm
The usage message for the innodb_compression_algorithm system variable
did not list snappy, which was added as an optional compression algorithm
in MariaDB 10.1.3 and might actually work since
commit 90c52e5291 (MDEV-12615)
in MariaDB 10.1.24.

Unfortunately, we will include also unavailable compression algorithms
in the list, because ENUM parameters allow numeric values, and we do
not want innodb_compression_algorithm=3 to change meaning depending on
the way how the source code was compiled.
2020-08-12 18:35:21 +03:00
Daniel Black
deb365581b MDEV-23386: mtr: main.mysqld--help autosized table{-open,}-cach and max-connections
Example of the failure:
http://buildbot.askmonty.org/buildbot/builders/bld-p9-rhel7/builds/4417/steps/mtr/logs/stdio
```
main.mysqld--help 'unix'                 w17 [ fail ]
        Test ended at 2020-06-20 18:51:45

CURRENT_TEST: main.mysqld--help
--- /opt/buildbot-slave/bld-p9-rhel7/build/mysql-test/main/mysqld--help.result	2020-06-20 16:06:49.903604179 +0300
+++ /opt/buildbot-slave/bld-p9-rhel7/build/mysql-test/main/mysqld--help.reject	2020-06-20 18:51:44.886766820 +0300
@@ -1797,10 +1797,10 @@
 sync-relay-log-info 10000
 sysdate-is-now FALSE
 system-versioning-alter-history ERROR
-table-cache 421
+table-cache 2000
 table-definition-cache 400
-table-open-cache 421
-table-open-cache-instances 1
+table-open-cache 2000
+table-open-cache-instances 8
 tc-heuristic-recover OFF
 tcp-keepalive-interval 0
 tcp-keepalive-probes 0

mysqltest: Result length mismatch
```
mtr: table_open_cache_basic autosized:

Lets assume that >400 are available and that
we can set the result back to the start value.

All of these system variables are autosized and can
generate MTR output differences.

Closes 
2020-08-10 11:58:56 +02:00
Oleksandr Byelkin
ef7cb0a0b5 Merge branch '10.1' into 10.2 2020-08-02 11:05:29 +02:00
Marko Mäkelä
4860fe244b XtraDB 5.6.49-89.0
The only change between Percona XtraDB Server 5.6.48-88.0
and 5.6.49-89.0 (apart from the version number change) was
percona/percona-server@25ec240920
which we had already addressed in
commit 7c03edf2fe and
commit c0fca2863b.
2020-07-30 11:06:46 +03:00
Varun Gupta
62d73df6b2 MDEV-19232: Floating point precision / value comparison problem
The issue occurs when the subquery_cache is enabled.
When there is a cache miss the division was leading to a value with scale 9.
In the case of cache hit the value returned was of scale 9 and due to the different
values for the scales the where condition evaluated to FALSE, hence the output
was incomplete.

To fix this problem we need to round up the decimal to the limit mentioned in
Item::decimals. This would make sure the values are compared with the same
scale.
2020-07-22 14:44:25 +05:30
Marko Mäkelä
646a6005e7 Merge 10.1 into 10.2 2020-07-14 15:10:59 +03:00
Marko Mäkelä
67a03b7c94 XtraDB 5.6.48-88.0
The only InnoDB changes between Percona XtraDB Server 5.6.47-87.0
and 5.6.48-88.0 are related to InnoDB changes between MySQL 5.6.47
and MySQL 5.6.48, which we had already applied.
2020-07-14 13:32:32 +03:00
Marko Mäkelä
142f85142a Update the InnoDB version number to 5.6.49
There were no InnoDB changes between MySQL 5.6.48 and MySQL 5.6.49.
2020-07-14 13:25:18 +03:00
Rucha Deodhar
0994af43e5 MDEV-22058: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status
Error state is not stored in check_and_do_in_subquery_rewrites() when there is
illegal combination of optimizer switches. So all the functions eventually
return false. Thus the assetion failure.
2020-07-12 20:03:32 +05:30
Marko Mäkelä
0df01ccb66 Merge 10.1 into 10.2 2020-06-06 18:07:04 +03:00
Varun Gupta
f30ff10c8d MDEV-22715: SIGSEGV in radixsort_for_str_ptr and in native_compare/my_qsort2 (optimized builds)
For DECIMAL[(M[,D])] datatype max_sort_length was not being honoured which was leading to buffer
overflow while making the sort key. The fix to this problem would be to create sort keys for decimals
with atmost max_sort_key bytes

Important:
The minimum value of max_sort_length has been raised to 8 (previously was 4),
so fixed size datatypes like DOUBLE and BIGINIT are not truncated for
lower values of max_sort_length.
2020-06-05 01:11:03 +05:30
Marko Mäkelä
e380f44742 Merge 10.1 into 10.2 2020-05-20 11:13:40 +03:00
Marko Mäkelä
6b2c8cac1b MDEV-22258 Limit innodb_encryption_threads to 255
For no good reason, innodb_encryption_threads was limited to
4,294,967,295. Expectedly, the server would crash if such an
insane value was specified. Let us limit the maximum to 255.

The encryption threads are not doing much useful work.
They are basically only dirtying pages by performing
dummy writes via the redo log. The encryption key rotation
or the in-place addition or removal of encryption
will take place in the page cleaner.

In a quick test on a 20-core CPU (40 threads in total),
the sweet spot on an otherwise idle server seemed to be
innodb_encryption_threads=16 for the test
encryption.encrypt_and_grep. The new limit 255 should be
more than enough for even bigger servers.
2020-05-20 10:33:53 +03:00
Marko Mäkelä
fc58c17216 MDEV-21336 Memory leaks related to innodb_debug_sync
This essentially reverts commit b393e2cb0c.

The leak might have been fixed, but because the
DEBUG_SYNC instrumentation for InnoDB purge threads was reverted
in 10.5 commit 5e62b6a5e0
as part of introducing a thread pool, it is easiest to revert
the entire change.
2020-05-14 13:36:11 +03:00
Marko Mäkelä
6bc4444d7c Merge 10.1 into 10.2 2020-05-13 11:12:31 +03:00
Marko Mäkelä
1887b5ae87 MDEV-22501 Various issues when using --innodb-data-file-size-debug=-1
Let us limit the maximum value of the debug parameter
innodb_data_file_size to 256 MiB. It is only being used
in the test innodb.log_data_file_size, and the size
of the system tablespace should never exceed some 70 MiB
in ./mtr. Thus, 256 MiB should be a reasonable limit.

The fact that negative values that are passed to unsigned parameters
wrap around to the maximum value appears to be a regression due to
commit 18ef02b04d
and has been filed as bug MDEV-22219.
2020-05-08 13:27:57 +03:00
Marko Mäkelä
547cb280b8 Merge 10.1 into 10.2 2020-04-28 19:39:40 +03:00
Marko Mäkelä
713e427b2e InnoDB 5.6.48 2020-04-28 16:20:19 +03:00